{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-6.8.0-147", "linux-headers-6.8.0-147-generic", "linux-image-6.8.0-147-generic", "linux-modules-6.8.0-147-generic", "linux-tools-6.8.0-147", "linux-tools-6.8.0-147-generic" ], "removed": [ "linux-headers-6.8.0-142", "linux-headers-6.8.0-142-generic", "linux-image-6.8.0-142-generic", "linux-modules-6.8.0-142-generic", "linux-tools-6.8.0-142", "linux-tools-6.8.0-142-generic" ], "diff": [ "apparmor", "bind9-dnsutils", "bind9-host", "bind9-libs:s390x", "curl", "dracut-install", "libapparmor1:s390x", "libarchive13t64:s390x", "libcurl3t64-gnutls:s390x", "libcurl4t64:s390x", "libevent-core-2.1-7t64:s390x", "libfreetype6:s390x", "libheif-plugin-aomdec:s390x", "libheif-plugin-aomenc:s390x", "libheif1:s390x", "libnss-systemd:s390x", "libopeniscsiusr", "libpam-systemd:s390x", "libpng16-16t64:s390x", "libsgutils2-1.46-2:s390x", "libssl3t64:s390x", "libsystemd-shared:s390x", "libsystemd0:s390x", "libudev1:s390x", "libx11-6:s390x", "libx11-data", "libxml2:s390x", "libxpm4:s390x", "linux-headers-generic", "linux-headers-virtual", "linux-image-virtual", "linux-libc-dev:s390x", "linux-tools-common", "linux-virtual", "open-iscsi", "openssh-client", "openssh-server", "openssh-sftp-server", "openssl", "python3-jwt", "python3-requests", "python3-urllib3", "sg3-utils", "sg3-utils-udev", "snapd", "sosreport", "sudo", "systemd", "systemd-dev", "systemd-resolved", "systemd-sysv", "systemd-timesyncd", "tzdata", "udev" ] } }, "diff": { "deb": [ { "name": "apparmor", "from_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.8", "version": "4.0.1really4.0.1-0ubuntu0.24.04.8" }, "to_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.9", "version": "4.0.1really4.0.1-0ubuntu0.24.04.9" }, "cves": [], "launchpad_bugs_fixed": [ 2083548 ], "changes": [ { "cves": [], "log": [ "", " * Fix transmission-daemon timeout inside systemd confinement. (LP: #2083548)", "" ], "package": "apparmor", "version": "4.0.1really4.0.1-0ubuntu0.24.04.9", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2083548 ], "author": "Willow Carlson-Huber ", "date": "Fri, 18 Sep 2026 12:52:55 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "bind9-dnsutils", "from_version": { "source_package_name": "bind9", "source_package_version": "1:9.18.39-0ubuntu0.24.04.7", "version": "1:9.18.39-0ubuntu0.24.04.7" }, "to_version": { "source_package_name": "bind9", "source_package_version": "1:9.18.39-0ubuntu0.24.04.8", "version": "1:9.18.39-0ubuntu0.24.04.8" }, "cves": [ { "cve": "CVE-2026-75029", "url": "https://ubuntu.com/security/CVE-2026-75029", "cve_description": "In a query response, an attacker may send `named` multiple copies of a record that should only exist once (such as an SOA record). If the RDATA is the same on all the copies, the record is appended to the in-memory RDATA set, which can cause increased memory usage of the negative cache and possibly lead to other memory attack vectors. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19666", "url": "https://ubuntu.com/security/CVE-2026-19666", "cve_description": "On a resolver configured to use ``dns64``, if an applicable answer from the authoritative server is malformed in a specific way, the resolver `named` process will exit unexpectedly. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19662", "url": "https://ubuntu.com/security/CVE-2026-19662", "cve_description": "An attacker may be able to cause a `named` resolver to abort. The attack requires inducing the victim resolver to send multiple queries for a DNSSEC-signed zone hosted by an authoritative server under the control of the attacker. If the auth responds with a particular sequence of crafted answers, and those answers arrive in a particular order with particular timing, the `named` resolver will encounter a use-after-free bug, and abort. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19941", "url": "https://ubuntu.com/security/CVE-2026-19941", "cve_description": "An inapplicable NSEC record may be accepted by a `named` resolver as proof that no wildcard exists, which could allow an attacker at the same or an upstream level of the zone name to mask the existence of a victim's wildcard record. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-78301", "url": "https://ubuntu.com/security/CVE-2026-78301", "cve_description": "A malformed zone may contain an NS or DNAME node above its origin, which `named` treats as a zone cut. If an attacker inserts a malformed zone into a BIND authoritative server (e.g., via zone transfer), queries for names inside the configured zone then lose authoritative status and return an out-of-zone delegation. On a server that also provides recursion BIND can follow this locally sourced cut and cache attacker-supplied data, affecting names outside the configured zone. This situation persists as long as the malformed zone remains in the zone database. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-81563", "url": "https://ubuntu.com/security/CVE-2026-81563", "cve_description": "A BIND resolver encountering an SVCB/HTTPS AliasMode record referencing 14 or more SVCB/HTTPS ServiceMode records may fail to properly deallocate internal resources. If this happens repeatedly, resource exhaustion will eventually prevent the resolver from performing new recursive lookups. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-77119", "url": "https://ubuntu.com/security/CVE-2026-77119", "cve_description": "A validly signed NSEC3 from an unrelated sibling zone may be accepted as an insecurity proof, downgrading a secure delegation and letting a forged unsigned answer through. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-80274", "url": "https://ubuntu.com/security/CVE-2026-80274", "cve_description": "If a BIND resolver sends a query for a DNSSEC-signed authoritative zone, and the authoritative server replies with a valid wildcard answer and signed NSEC3 proof, followed by an unsigned NSEC at the same owner name, it will trigger an unexpected program exit. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19033", "url": "https://ubuntu.com/security/CVE-2026-19033", "cve_description": "For a secondary zone with transfers restricted by TSIG, `named` may start to serve the data provided in a zone transfer before the final message with the TSIG signature arrives. This could allow an attacker that does not actually possess a valid TSIG signature to send unauthorized zone contents to a secondary server. Although no TSIG signature ever arrives, `named` does not rollback to the pre-transfer state. To exploit the vulnerability, the transfer must be a multi-message TCP IXFR, as described by RFC 8945. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-81736", "url": "https://ubuntu.com/security/CVE-2026-81736", "cve_description": "If a BIND resolver has cached a tree of SVCB/HTTPS AliasMode records, and is then queried for the root of that tree, the resolver will spend disproportionate CPU time constructing the response. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19667", "url": "https://ubuntu.com/security/CVE-2026-19667", "cve_description": "If an attacker-controlled authoritative server can produce a negative answer that is exactly 65536 bytes, then a flaw in `named` results in a negative cache entry of 0 bytes. When this entry is subsequently read, `named` aborts. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-75029", "url": "https://ubuntu.com/security/CVE-2026-75029", "cve_description": "In a query response, an attacker may send `named` multiple copies of a record that should only exist once (such as an SOA record). If the RDATA is the same on all the copies, the record is appended to the in-memory RDATA set, which can cause increased memory usage of the negative cache and possibly lead to other memory attack vectors. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19666", "url": "https://ubuntu.com/security/CVE-2026-19666", "cve_description": "On a resolver configured to use ``dns64``, if an applicable answer from the authoritative server is malformed in a specific way, the resolver `named` process will exit unexpectedly. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19662", "url": "https://ubuntu.com/security/CVE-2026-19662", "cve_description": "An attacker may be able to cause a `named` resolver to abort. The attack requires inducing the victim resolver to send multiple queries for a DNSSEC-signed zone hosted by an authoritative server under the control of the attacker. If the auth responds with a particular sequence of crafted answers, and those answers arrive in a particular order with particular timing, the `named` resolver will encounter a use-after-free bug, and abort. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19941", "url": "https://ubuntu.com/security/CVE-2026-19941", "cve_description": "An inapplicable NSEC record may be accepted by a `named` resolver as proof that no wildcard exists, which could allow an attacker at the same or an upstream level of the zone name to mask the existence of a victim's wildcard record. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-78301", "url": "https://ubuntu.com/security/CVE-2026-78301", "cve_description": "A malformed zone may contain an NS or DNAME node above its origin, which `named` treats as a zone cut. If an attacker inserts a malformed zone into a BIND authoritative server (e.g., via zone transfer), queries for names inside the configured zone then lose authoritative status and return an out-of-zone delegation. On a server that also provides recursion BIND can follow this locally sourced cut and cache attacker-supplied data, affecting names outside the configured zone. This situation persists as long as the malformed zone remains in the zone database. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-81563", "url": "https://ubuntu.com/security/CVE-2026-81563", "cve_description": "A BIND resolver encountering an SVCB/HTTPS AliasMode record referencing 14 or more SVCB/HTTPS ServiceMode records may fail to properly deallocate internal resources. If this happens repeatedly, resource exhaustion will eventually prevent the resolver from performing new recursive lookups. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-77119", "url": "https://ubuntu.com/security/CVE-2026-77119", "cve_description": "A validly signed NSEC3 from an unrelated sibling zone may be accepted as an insecurity proof, downgrading a secure delegation and letting a forged unsigned answer through. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-80274", "url": "https://ubuntu.com/security/CVE-2026-80274", "cve_description": "If a BIND resolver sends a query for a DNSSEC-signed authoritative zone, and the authoritative server replies with a valid wildcard answer and signed NSEC3 proof, followed by an unsigned NSEC at the same owner name, it will trigger an unexpected program exit. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19033", "url": "https://ubuntu.com/security/CVE-2026-19033", "cve_description": "For a secondary zone with transfers restricted by TSIG, `named` may start to serve the data provided in a zone transfer before the final message with the TSIG signature arrives. This could allow an attacker that does not actually possess a valid TSIG signature to send unauthorized zone contents to a secondary server. Although no TSIG signature ever arrives, `named` does not rollback to the pre-transfer state. To exploit the vulnerability, the transfer must be a multi-message TCP IXFR, as described by RFC 8945. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-81736", "url": "https://ubuntu.com/security/CVE-2026-81736", "cve_description": "If a BIND resolver has cached a tree of SVCB/HTTPS AliasMode records, and is then queried for the root of that tree, the resolver will spend disproportionate CPU time constructing the response. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19667", "url": "https://ubuntu.com/security/CVE-2026-19667", "cve_description": "If an attacker-controlled authoritative server can produce a negative answer that is exactly 65536 bytes, then a flaw in `named` results in a negative cache entry of 0 bytes. When this entry is subsequently read, `named` aborts. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Excessive memory usage via repeated SOA, CNAME, or DNAME", " records", " - debian/patches/CVE-2026-75029-1.patch: Skip duplicate singleton records in", " lib/dns/message.c.", " - debian/patches/CVE-2026-75029-2.patch: Add a unit test for repeated", " singleton records in a message in tests/dns/Makefile.am,", " tests/dns/message_test.c.", " - CVE-2026-75029", " * SECURITY UPDATE: Unexpected exit with DNS64 and malformed answers", " - debian/patches/CVE-2026-19666-1.patch: Clear the noqname alias on the", " DNS64 filter64 path in lib/ns/query.c.", " - debian/patches/CVE-2026-19666-2.patch: Test the DNS64 filter64 path", " against a cached NOQNAME proof in bin/tests/system/dns64/ns1/example.db,", " bin/tests/system/dns64/ns2/named.conf.in, bin/tests/system/dns64/tests.sh.", " - CVE-2026-19666", " * SECURITY UPDATE: Unexpected exit via use-after-free with cached DNSSEC", " proofs", " - debian/patches/CVE-2026-19662-pre1.patch: Remove unused closest encloser", " proof caching in lib/dns/dnsrps.c, lib/dns/include/dns/rdataset.h,", " lib/dns/keytable.c, lib/dns/ncache.c, lib/dns/rbtdb.c,", " lib/dns/rdatalist.c, lib/dns/rdatalist_p.h, lib/dns/rdataset.c,", " lib/dns/resolver.c, lib/dns/sdb.c, lib/dns/sdlz.c, lib/ns/query.c.", " - debian/patches/CVE-2026-19662-1.patch: Keep NOQNAME proof slabheaders", " alive in lib/dns/rbtdb.c.", " - debian/patches/CVE-2026-19662-2.patch: Test NOQNAME proof slabheader", " lifetime in tests/dns/rbtdb_test.c.", " - CVE-2026-19662", " * SECURITY UPDATE: Forged NXDOMAIN via inapplicable NSEC wildcard proof", " - debian/patches/CVE-2026-19941-1.patch: Require NSEC wildcard proofs from", " the same zone in lib/dns/include/dns/validator.h, lib/dns/validator.c.", " - debian/patches/CVE-2026-19941-2.patch: Test rejection of cross-zone NSEC", " wildcard proofs in bin/tests/system/Makefile.am,", " bin/tests/system/conf.sh.common,", " bin/tests/system/nsec_wildcard_wrong_zone/ans1/ans.py,", " bin/tests/system/nsec_wildcard_wrong_zone/ns2/named.conf.j2, bin/tests/sys", " tem/nsec_wildcard_wrong_zone/tests_nsec_wildcard_wrong_zone.py.", " - CVE-2026-19941", " * SECURITY UPDATE: Out-of-zone records served as authoritative", " - debian/patches/CVE-2026-78301-1.patch: Test that nodes above the zone apex", " are not zone cuts in bin/tests/system/outofzone_zonecut/ns1/attacker.db,", " bin/tests/system/outofzone_zonecut/ns1/example.db,", " bin/tests/system/outofzone_zonecut/ns1/named.conf.j2,", " bin/tests/system/outofzone_zonecut/ns1/root.db,", " bin/tests/system/outofzone_zonecut/ns2/dnamezone.db,", " bin/tests/system/outofzone_zonecut/ns2/named.conf.j2,", " bin/tests/system/outofzone_zonecut/ns2/nszone.db,", " bin/tests/system/outofzone_zonecut/ns3/dnamezone.db,", " bin/tests/system/outofzone_zonecut/ns3/named.conf.j2,", " bin/tests/system/outofzone_zonecut/ns3/nszone.db,", " bin/tests/system/outofzone_zonecut/tests_outofzone_zonecut.py.", " - debian/patches/CVE-2026-78301-2.patch: Ignore nodes above the zone origin", " in RBT zone database lookups in lib/dns/rbtdb.c, tests/dns/rbtdb_test.c.", " - CVE-2026-78301", " * SECURITY UPDATE: Resource exhaustion via HTTPS/SVCB AliasMode records", " - debian/patches/CVE-2026-81563-1.patch: Add a system test for HTTPS", " AliasMode additional-data errors in", " bin/tests/system/additional/ns1/https.db,", " bin/tests/system/additional/ns1/named1.conf.in,", " bin/tests/system/additional/ns1/named2.conf.in,", " bin/tests/system/additional/ns1/named3.conf.in,", " bin/tests/system/additional/ns1/named4.conf.in,", " bin/tests/system/additional/ns2/root.db,", " bin/tests/system/additional/ns3/named.conf.in,", " bin/tests/system/additional/tests_https_alias.py.", " - debian/patches/CVE-2026-81563-2.patch: Release the rdataset when SVCB", " additional-data lookups fail in lib/dns/rdata/in_1/svcb_64.c.", " - CVE-2026-81563", " * SECURITY UPDATE: DNSSEC downgrade via NSEC3 from an unrelated sibling zone", " - debian/patches/CVE-2026-77119-2.patch: Reject out-of-zone NSEC3 in the", " insecure-referral proof in lib/dns/validator.c.", " - CVE-2026-77119", " * SECURITY UPDATE: Unexpected exit on wildcard answers with NSEC and NSEC3", " proofs", " - debian/patches/CVE-2026-80274-1.patch: Keep NOQNAME proof selection", " consistent in lib/dns/include/dns/rdataset.h,", " lib/dns/include/dns/validator.h, lib/dns/rdatalist.c,", " lib/dns/rdatalist_p.h, lib/dns/rdataset.c, lib/dns/resolver.c,", " lib/dns/validator.c, tests/dns/rbtdb_test.c.", " - debian/patches/CVE-2026-80274-2.patch: Test NOQNAME proof selection in the", " rdataset unit test in tests/dns/rdataset_test.c.", " - debian/patches/CVE-2026-80274-3.patch: Make the findnoqname mismatch", " system test reach the resolver in", " bin/tests/system/dnssec_findnoqname_mismatch/ans1/ans.py, bin/tests/system", " /dnssec_findnoqname_mismatch/tests_findnoqname_mismatch.py.", " - CVE-2026-80274", " * SECURITY UPDATE: Zone transfer data used before TSIG verification", " - debian/patches/CVE-2026-19033.patch: Remove support for sparse TSIG in", " lib/dns/xfrin.c.", " - CVE-2026-19033", " * SECURITY UPDATE: Excessive CPU usage via cached HTTPS/SVCB AliasMode records", " - debian/patches/CVE-2026-81736-1.patch: Bound the total additional", " processing for a single query in lib/ns/client.c,", " lib/ns/include/ns/client.h, lib/ns/query.c.", " - debian/patches/CVE-2026-81736-2.patch: Add a system test for SVCB/HTTPS", " AliasMode additional processing in", " bin/tests/system/additional/ns1/https.db,", " bin/tests/system/additional/tests_https_alias.py,", " bin/tests/system/svcb_alias/ns1/named.conf.j2,", " bin/tests/system/svcb_alias/ns1/root.hint,", " bin/tests/system/svcb_alias/ns2/named.conf.j2,", " bin/tests/system/svcb_alias/ns2/root.db,", " bin/tests/system/svcb_alias/setup.sh,", " bin/tests/system/svcb_alias/tests_svcb_alias.py.", " - CVE-2026-81736", " * SECURITY UPDATE: Unexpected exit via oversized negative cache records", " - debian/patches/CVE-2026-19667-1.patch: Reject negative cache records that", " do not fit in a dns_rdata_t in lib/dns/ncache.c.", " - debian/patches/CVE-2026-19667-2.patch: Test that an oversized negative", " cache record is rejected in tests/dns/Makefile.am,", " tests/dns/ncache_test.c.", " - CVE-2026-19667", "" ], "package": "bind9", "version": "1:9.18.39-0ubuntu0.24.04.8", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "John Breton ", "date": "Fri, 09 Oct 2026 12:07:30 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "bind9-host", "from_version": { "source_package_name": "bind9", "source_package_version": "1:9.18.39-0ubuntu0.24.04.7", "version": "1:9.18.39-0ubuntu0.24.04.7" }, "to_version": { "source_package_name": "bind9", "source_package_version": "1:9.18.39-0ubuntu0.24.04.8", "version": "1:9.18.39-0ubuntu0.24.04.8" }, "cves": [ { "cve": "CVE-2026-75029", "url": "https://ubuntu.com/security/CVE-2026-75029", "cve_description": "In a query response, an attacker may send `named` multiple copies of a record that should only exist once (such as an SOA record). If the RDATA is the same on all the copies, the record is appended to the in-memory RDATA set, which can cause increased memory usage of the negative cache and possibly lead to other memory attack vectors. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19666", "url": "https://ubuntu.com/security/CVE-2026-19666", "cve_description": "On a resolver configured to use ``dns64``, if an applicable answer from the authoritative server is malformed in a specific way, the resolver `named` process will exit unexpectedly. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19662", "url": "https://ubuntu.com/security/CVE-2026-19662", "cve_description": "An attacker may be able to cause a `named` resolver to abort. The attack requires inducing the victim resolver to send multiple queries for a DNSSEC-signed zone hosted by an authoritative server under the control of the attacker. If the auth responds with a particular sequence of crafted answers, and those answers arrive in a particular order with particular timing, the `named` resolver will encounter a use-after-free bug, and abort. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19941", "url": "https://ubuntu.com/security/CVE-2026-19941", "cve_description": "An inapplicable NSEC record may be accepted by a `named` resolver as proof that no wildcard exists, which could allow an attacker at the same or an upstream level of the zone name to mask the existence of a victim's wildcard record. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-78301", "url": "https://ubuntu.com/security/CVE-2026-78301", "cve_description": "A malformed zone may contain an NS or DNAME node above its origin, which `named` treats as a zone cut. If an attacker inserts a malformed zone into a BIND authoritative server (e.g., via zone transfer), queries for names inside the configured zone then lose authoritative status and return an out-of-zone delegation. On a server that also provides recursion BIND can follow this locally sourced cut and cache attacker-supplied data, affecting names outside the configured zone. This situation persists as long as the malformed zone remains in the zone database. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-81563", "url": "https://ubuntu.com/security/CVE-2026-81563", "cve_description": "A BIND resolver encountering an SVCB/HTTPS AliasMode record referencing 14 or more SVCB/HTTPS ServiceMode records may fail to properly deallocate internal resources. If this happens repeatedly, resource exhaustion will eventually prevent the resolver from performing new recursive lookups. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-77119", "url": "https://ubuntu.com/security/CVE-2026-77119", "cve_description": "A validly signed NSEC3 from an unrelated sibling zone may be accepted as an insecurity proof, downgrading a secure delegation and letting a forged unsigned answer through. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-80274", "url": "https://ubuntu.com/security/CVE-2026-80274", "cve_description": "If a BIND resolver sends a query for a DNSSEC-signed authoritative zone, and the authoritative server replies with a valid wildcard answer and signed NSEC3 proof, followed by an unsigned NSEC at the same owner name, it will trigger an unexpected program exit. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19033", "url": "https://ubuntu.com/security/CVE-2026-19033", "cve_description": "For a secondary zone with transfers restricted by TSIG, `named` may start to serve the data provided in a zone transfer before the final message with the TSIG signature arrives. This could allow an attacker that does not actually possess a valid TSIG signature to send unauthorized zone contents to a secondary server. Although no TSIG signature ever arrives, `named` does not rollback to the pre-transfer state. To exploit the vulnerability, the transfer must be a multi-message TCP IXFR, as described by RFC 8945. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-81736", "url": "https://ubuntu.com/security/CVE-2026-81736", "cve_description": "If a BIND resolver has cached a tree of SVCB/HTTPS AliasMode records, and is then queried for the root of that tree, the resolver will spend disproportionate CPU time constructing the response. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19667", "url": "https://ubuntu.com/security/CVE-2026-19667", "cve_description": "If an attacker-controlled authoritative server can produce a negative answer that is exactly 65536 bytes, then a flaw in `named` results in a negative cache entry of 0 bytes. When this entry is subsequently read, `named` aborts. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-75029", "url": "https://ubuntu.com/security/CVE-2026-75029", "cve_description": "In a query response, an attacker may send `named` multiple copies of a record that should only exist once (such as an SOA record). If the RDATA is the same on all the copies, the record is appended to the in-memory RDATA set, which can cause increased memory usage of the negative cache and possibly lead to other memory attack vectors. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19666", "url": "https://ubuntu.com/security/CVE-2026-19666", "cve_description": "On a resolver configured to use ``dns64``, if an applicable answer from the authoritative server is malformed in a specific way, the resolver `named` process will exit unexpectedly. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19662", "url": "https://ubuntu.com/security/CVE-2026-19662", "cve_description": "An attacker may be able to cause a `named` resolver to abort. The attack requires inducing the victim resolver to send multiple queries for a DNSSEC-signed zone hosted by an authoritative server under the control of the attacker. If the auth responds with a particular sequence of crafted answers, and those answers arrive in a particular order with particular timing, the `named` resolver will encounter a use-after-free bug, and abort. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19941", "url": "https://ubuntu.com/security/CVE-2026-19941", "cve_description": "An inapplicable NSEC record may be accepted by a `named` resolver as proof that no wildcard exists, which could allow an attacker at the same or an upstream level of the zone name to mask the existence of a victim's wildcard record. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-78301", "url": "https://ubuntu.com/security/CVE-2026-78301", "cve_description": "A malformed zone may contain an NS or DNAME node above its origin, which `named` treats as a zone cut. If an attacker inserts a malformed zone into a BIND authoritative server (e.g., via zone transfer), queries for names inside the configured zone then lose authoritative status and return an out-of-zone delegation. On a server that also provides recursion BIND can follow this locally sourced cut and cache attacker-supplied data, affecting names outside the configured zone. This situation persists as long as the malformed zone remains in the zone database. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-81563", "url": "https://ubuntu.com/security/CVE-2026-81563", "cve_description": "A BIND resolver encountering an SVCB/HTTPS AliasMode record referencing 14 or more SVCB/HTTPS ServiceMode records may fail to properly deallocate internal resources. If this happens repeatedly, resource exhaustion will eventually prevent the resolver from performing new recursive lookups. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-77119", "url": "https://ubuntu.com/security/CVE-2026-77119", "cve_description": "A validly signed NSEC3 from an unrelated sibling zone may be accepted as an insecurity proof, downgrading a secure delegation and letting a forged unsigned answer through. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-80274", "url": "https://ubuntu.com/security/CVE-2026-80274", "cve_description": "If a BIND resolver sends a query for a DNSSEC-signed authoritative zone, and the authoritative server replies with a valid wildcard answer and signed NSEC3 proof, followed by an unsigned NSEC at the same owner name, it will trigger an unexpected program exit. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19033", "url": "https://ubuntu.com/security/CVE-2026-19033", "cve_description": "For a secondary zone with transfers restricted by TSIG, `named` may start to serve the data provided in a zone transfer before the final message with the TSIG signature arrives. This could allow an attacker that does not actually possess a valid TSIG signature to send unauthorized zone contents to a secondary server. Although no TSIG signature ever arrives, `named` does not rollback to the pre-transfer state. To exploit the vulnerability, the transfer must be a multi-message TCP IXFR, as described by RFC 8945. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-81736", "url": "https://ubuntu.com/security/CVE-2026-81736", "cve_description": "If a BIND resolver has cached a tree of SVCB/HTTPS AliasMode records, and is then queried for the root of that tree, the resolver will spend disproportionate CPU time constructing the response. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19667", "url": "https://ubuntu.com/security/CVE-2026-19667", "cve_description": "If an attacker-controlled authoritative server can produce a negative answer that is exactly 65536 bytes, then a flaw in `named` results in a negative cache entry of 0 bytes. When this entry is subsequently read, `named` aborts. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Excessive memory usage via repeated SOA, CNAME, or DNAME", " records", " - debian/patches/CVE-2026-75029-1.patch: Skip duplicate singleton records in", " lib/dns/message.c.", " - debian/patches/CVE-2026-75029-2.patch: Add a unit test for repeated", " singleton records in a message in tests/dns/Makefile.am,", " tests/dns/message_test.c.", " - CVE-2026-75029", " * SECURITY UPDATE: Unexpected exit with DNS64 and malformed answers", " - debian/patches/CVE-2026-19666-1.patch: Clear the noqname alias on the", " DNS64 filter64 path in lib/ns/query.c.", " - debian/patches/CVE-2026-19666-2.patch: Test the DNS64 filter64 path", " against a cached NOQNAME proof in bin/tests/system/dns64/ns1/example.db,", " bin/tests/system/dns64/ns2/named.conf.in, bin/tests/system/dns64/tests.sh.", " - CVE-2026-19666", " * SECURITY UPDATE: Unexpected exit via use-after-free with cached DNSSEC", " proofs", " - debian/patches/CVE-2026-19662-pre1.patch: Remove unused closest encloser", " proof caching in lib/dns/dnsrps.c, lib/dns/include/dns/rdataset.h,", " lib/dns/keytable.c, lib/dns/ncache.c, lib/dns/rbtdb.c,", " lib/dns/rdatalist.c, lib/dns/rdatalist_p.h, lib/dns/rdataset.c,", " lib/dns/resolver.c, lib/dns/sdb.c, lib/dns/sdlz.c, lib/ns/query.c.", " - debian/patches/CVE-2026-19662-1.patch: Keep NOQNAME proof slabheaders", " alive in lib/dns/rbtdb.c.", " - debian/patches/CVE-2026-19662-2.patch: Test NOQNAME proof slabheader", " lifetime in tests/dns/rbtdb_test.c.", " - CVE-2026-19662", " * SECURITY UPDATE: Forged NXDOMAIN via inapplicable NSEC wildcard proof", " - debian/patches/CVE-2026-19941-1.patch: Require NSEC wildcard proofs from", " the same zone in lib/dns/include/dns/validator.h, lib/dns/validator.c.", " - debian/patches/CVE-2026-19941-2.patch: Test rejection of cross-zone NSEC", " wildcard proofs in bin/tests/system/Makefile.am,", " bin/tests/system/conf.sh.common,", " bin/tests/system/nsec_wildcard_wrong_zone/ans1/ans.py,", " bin/tests/system/nsec_wildcard_wrong_zone/ns2/named.conf.j2, bin/tests/sys", " tem/nsec_wildcard_wrong_zone/tests_nsec_wildcard_wrong_zone.py.", " - CVE-2026-19941", " * SECURITY UPDATE: Out-of-zone records served as authoritative", " - debian/patches/CVE-2026-78301-1.patch: Test that nodes above the zone apex", " are not zone cuts in bin/tests/system/outofzone_zonecut/ns1/attacker.db,", " bin/tests/system/outofzone_zonecut/ns1/example.db,", " bin/tests/system/outofzone_zonecut/ns1/named.conf.j2,", " bin/tests/system/outofzone_zonecut/ns1/root.db,", " bin/tests/system/outofzone_zonecut/ns2/dnamezone.db,", " bin/tests/system/outofzone_zonecut/ns2/named.conf.j2,", " bin/tests/system/outofzone_zonecut/ns2/nszone.db,", " bin/tests/system/outofzone_zonecut/ns3/dnamezone.db,", " bin/tests/system/outofzone_zonecut/ns3/named.conf.j2,", " bin/tests/system/outofzone_zonecut/ns3/nszone.db,", " bin/tests/system/outofzone_zonecut/tests_outofzone_zonecut.py.", " - debian/patches/CVE-2026-78301-2.patch: Ignore nodes above the zone origin", " in RBT zone database lookups in lib/dns/rbtdb.c, tests/dns/rbtdb_test.c.", " - CVE-2026-78301", " * SECURITY UPDATE: Resource exhaustion via HTTPS/SVCB AliasMode records", " - debian/patches/CVE-2026-81563-1.patch: Add a system test for HTTPS", " AliasMode additional-data errors in", " bin/tests/system/additional/ns1/https.db,", " bin/tests/system/additional/ns1/named1.conf.in,", " bin/tests/system/additional/ns1/named2.conf.in,", " bin/tests/system/additional/ns1/named3.conf.in,", " bin/tests/system/additional/ns1/named4.conf.in,", " bin/tests/system/additional/ns2/root.db,", " bin/tests/system/additional/ns3/named.conf.in,", " bin/tests/system/additional/tests_https_alias.py.", " - debian/patches/CVE-2026-81563-2.patch: Release the rdataset when SVCB", " additional-data lookups fail in lib/dns/rdata/in_1/svcb_64.c.", " - CVE-2026-81563", " * SECURITY UPDATE: DNSSEC downgrade via NSEC3 from an unrelated sibling zone", " - debian/patches/CVE-2026-77119-2.patch: Reject out-of-zone NSEC3 in the", " insecure-referral proof in lib/dns/validator.c.", " - CVE-2026-77119", " * SECURITY UPDATE: Unexpected exit on wildcard answers with NSEC and NSEC3", " proofs", " - debian/patches/CVE-2026-80274-1.patch: Keep NOQNAME proof selection", " consistent in lib/dns/include/dns/rdataset.h,", " lib/dns/include/dns/validator.h, lib/dns/rdatalist.c,", " lib/dns/rdatalist_p.h, lib/dns/rdataset.c, lib/dns/resolver.c,", " lib/dns/validator.c, tests/dns/rbtdb_test.c.", " - debian/patches/CVE-2026-80274-2.patch: Test NOQNAME proof selection in the", " rdataset unit test in tests/dns/rdataset_test.c.", " - debian/patches/CVE-2026-80274-3.patch: Make the findnoqname mismatch", " system test reach the resolver in", " bin/tests/system/dnssec_findnoqname_mismatch/ans1/ans.py, bin/tests/system", " /dnssec_findnoqname_mismatch/tests_findnoqname_mismatch.py.", " - CVE-2026-80274", " * SECURITY UPDATE: Zone transfer data used before TSIG verification", " - debian/patches/CVE-2026-19033.patch: Remove support for sparse TSIG in", " lib/dns/xfrin.c.", " - CVE-2026-19033", " * SECURITY UPDATE: Excessive CPU usage via cached HTTPS/SVCB AliasMode records", " - debian/patches/CVE-2026-81736-1.patch: Bound the total additional", " processing for a single query in lib/ns/client.c,", " lib/ns/include/ns/client.h, lib/ns/query.c.", " - debian/patches/CVE-2026-81736-2.patch: Add a system test for SVCB/HTTPS", " AliasMode additional processing in", " bin/tests/system/additional/ns1/https.db,", " bin/tests/system/additional/tests_https_alias.py,", " bin/tests/system/svcb_alias/ns1/named.conf.j2,", " bin/tests/system/svcb_alias/ns1/root.hint,", " bin/tests/system/svcb_alias/ns2/named.conf.j2,", " bin/tests/system/svcb_alias/ns2/root.db,", " bin/tests/system/svcb_alias/setup.sh,", " bin/tests/system/svcb_alias/tests_svcb_alias.py.", " - CVE-2026-81736", " * SECURITY UPDATE: Unexpected exit via oversized negative cache records", " - debian/patches/CVE-2026-19667-1.patch: Reject negative cache records that", " do not fit in a dns_rdata_t in lib/dns/ncache.c.", " - debian/patches/CVE-2026-19667-2.patch: Test that an oversized negative", " cache record is rejected in tests/dns/Makefile.am,", " tests/dns/ncache_test.c.", " - CVE-2026-19667", "" ], "package": "bind9", "version": "1:9.18.39-0ubuntu0.24.04.8", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "John Breton ", "date": "Fri, 09 Oct 2026 12:07:30 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "bind9-libs:s390x", "from_version": { "source_package_name": "bind9", "source_package_version": "1:9.18.39-0ubuntu0.24.04.7", "version": "1:9.18.39-0ubuntu0.24.04.7" }, "to_version": { "source_package_name": "bind9", "source_package_version": "1:9.18.39-0ubuntu0.24.04.8", "version": "1:9.18.39-0ubuntu0.24.04.8" }, "cves": [ { "cve": "CVE-2026-75029", "url": "https://ubuntu.com/security/CVE-2026-75029", "cve_description": "In a query response, an attacker may send `named` multiple copies of a record that should only exist once (such as an SOA record). If the RDATA is the same on all the copies, the record is appended to the in-memory RDATA set, which can cause increased memory usage of the negative cache and possibly lead to other memory attack vectors. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19666", "url": "https://ubuntu.com/security/CVE-2026-19666", "cve_description": "On a resolver configured to use ``dns64``, if an applicable answer from the authoritative server is malformed in a specific way, the resolver `named` process will exit unexpectedly. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19662", "url": "https://ubuntu.com/security/CVE-2026-19662", "cve_description": "An attacker may be able to cause a `named` resolver to abort. The attack requires inducing the victim resolver to send multiple queries for a DNSSEC-signed zone hosted by an authoritative server under the control of the attacker. If the auth responds with a particular sequence of crafted answers, and those answers arrive in a particular order with particular timing, the `named` resolver will encounter a use-after-free bug, and abort. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19941", "url": "https://ubuntu.com/security/CVE-2026-19941", "cve_description": "An inapplicable NSEC record may be accepted by a `named` resolver as proof that no wildcard exists, which could allow an attacker at the same or an upstream level of the zone name to mask the existence of a victim's wildcard record. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-78301", "url": "https://ubuntu.com/security/CVE-2026-78301", "cve_description": "A malformed zone may contain an NS or DNAME node above its origin, which `named` treats as a zone cut. If an attacker inserts a malformed zone into a BIND authoritative server (e.g., via zone transfer), queries for names inside the configured zone then lose authoritative status and return an out-of-zone delegation. On a server that also provides recursion BIND can follow this locally sourced cut and cache attacker-supplied data, affecting names outside the configured zone. This situation persists as long as the malformed zone remains in the zone database. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-81563", "url": "https://ubuntu.com/security/CVE-2026-81563", "cve_description": "A BIND resolver encountering an SVCB/HTTPS AliasMode record referencing 14 or more SVCB/HTTPS ServiceMode records may fail to properly deallocate internal resources. If this happens repeatedly, resource exhaustion will eventually prevent the resolver from performing new recursive lookups. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-77119", "url": "https://ubuntu.com/security/CVE-2026-77119", "cve_description": "A validly signed NSEC3 from an unrelated sibling zone may be accepted as an insecurity proof, downgrading a secure delegation and letting a forged unsigned answer through. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-80274", "url": "https://ubuntu.com/security/CVE-2026-80274", "cve_description": "If a BIND resolver sends a query for a DNSSEC-signed authoritative zone, and the authoritative server replies with a valid wildcard answer and signed NSEC3 proof, followed by an unsigned NSEC at the same owner name, it will trigger an unexpected program exit. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19033", "url": "https://ubuntu.com/security/CVE-2026-19033", "cve_description": "For a secondary zone with transfers restricted by TSIG, `named` may start to serve the data provided in a zone transfer before the final message with the TSIG signature arrives. This could allow an attacker that does not actually possess a valid TSIG signature to send unauthorized zone contents to a secondary server. Although no TSIG signature ever arrives, `named` does not rollback to the pre-transfer state. To exploit the vulnerability, the transfer must be a multi-message TCP IXFR, as described by RFC 8945. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-81736", "url": "https://ubuntu.com/security/CVE-2026-81736", "cve_description": "If a BIND resolver has cached a tree of SVCB/HTTPS AliasMode records, and is then queried for the root of that tree, the resolver will spend disproportionate CPU time constructing the response. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19667", "url": "https://ubuntu.com/security/CVE-2026-19667", "cve_description": "If an attacker-controlled authoritative server can produce a negative answer that is exactly 65536 bytes, then a flaw in `named` results in a negative cache entry of 0 bytes. When this entry is subsequently read, `named` aborts. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-75029", "url": "https://ubuntu.com/security/CVE-2026-75029", "cve_description": "In a query response, an attacker may send `named` multiple copies of a record that should only exist once (such as an SOA record). If the RDATA is the same on all the copies, the record is appended to the in-memory RDATA set, which can cause increased memory usage of the negative cache and possibly lead to other memory attack vectors. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19666", "url": "https://ubuntu.com/security/CVE-2026-19666", "cve_description": "On a resolver configured to use ``dns64``, if an applicable answer from the authoritative server is malformed in a specific way, the resolver `named` process will exit unexpectedly. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19662", "url": "https://ubuntu.com/security/CVE-2026-19662", "cve_description": "An attacker may be able to cause a `named` resolver to abort. The attack requires inducing the victim resolver to send multiple queries for a DNSSEC-signed zone hosted by an authoritative server under the control of the attacker. If the auth responds with a particular sequence of crafted answers, and those answers arrive in a particular order with particular timing, the `named` resolver will encounter a use-after-free bug, and abort. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19941", "url": "https://ubuntu.com/security/CVE-2026-19941", "cve_description": "An inapplicable NSEC record may be accepted by a `named` resolver as proof that no wildcard exists, which could allow an attacker at the same or an upstream level of the zone name to mask the existence of a victim's wildcard record. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-78301", "url": "https://ubuntu.com/security/CVE-2026-78301", "cve_description": "A malformed zone may contain an NS or DNAME node above its origin, which `named` treats as a zone cut. If an attacker inserts a malformed zone into a BIND authoritative server (e.g., via zone transfer), queries for names inside the configured zone then lose authoritative status and return an out-of-zone delegation. On a server that also provides recursion BIND can follow this locally sourced cut and cache attacker-supplied data, affecting names outside the configured zone. This situation persists as long as the malformed zone remains in the zone database. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-81563", "url": "https://ubuntu.com/security/CVE-2026-81563", "cve_description": "A BIND resolver encountering an SVCB/HTTPS AliasMode record referencing 14 or more SVCB/HTTPS ServiceMode records may fail to properly deallocate internal resources. If this happens repeatedly, resource exhaustion will eventually prevent the resolver from performing new recursive lookups. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-77119", "url": "https://ubuntu.com/security/CVE-2026-77119", "cve_description": "A validly signed NSEC3 from an unrelated sibling zone may be accepted as an insecurity proof, downgrading a secure delegation and letting a forged unsigned answer through. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-80274", "url": "https://ubuntu.com/security/CVE-2026-80274", "cve_description": "If a BIND resolver sends a query for a DNSSEC-signed authoritative zone, and the authoritative server replies with a valid wildcard answer and signed NSEC3 proof, followed by an unsigned NSEC at the same owner name, it will trigger an unexpected program exit. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-19033", "url": "https://ubuntu.com/security/CVE-2026-19033", "cve_description": "For a secondary zone with transfers restricted by TSIG, `named` may start to serve the data provided in a zone transfer before the final message with the TSIG signature arrives. This could allow an attacker that does not actually possess a valid TSIG signature to send unauthorized zone contents to a secondary server. Although no TSIG signature ever arrives, `named` does not rollback to the pre-transfer state. To exploit the vulnerability, the transfer must be a multi-message TCP IXFR, as described by RFC 8945. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 15:17:00 UTC" }, { "cve": "CVE-2026-81736", "url": "https://ubuntu.com/security/CVE-2026-81736", "cve_description": "If a BIND resolver has cached a tree of SVCB/HTTPS AliasMode records, and is then queried for the root of that tree, the resolver will spend disproportionate CPU time constructing the response. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" }, { "cve": "CVE-2026-19667", "url": "https://ubuntu.com/security/CVE-2026-19667", "cve_description": "If an attacker-controlled authoritative server can produce a negative answer that is exactly 65536 bytes, then a flaw in `named` results in a negative cache entry of 0 bytes. When this entry is subsequently read, `named` aborts. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.", "cve_priority": "medium", "cve_public_date": "2026-09-16 14:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Excessive memory usage via repeated SOA, CNAME, or DNAME", " records", " - debian/patches/CVE-2026-75029-1.patch: Skip duplicate singleton records in", " lib/dns/message.c.", " - debian/patches/CVE-2026-75029-2.patch: Add a unit test for repeated", " singleton records in a message in tests/dns/Makefile.am,", " tests/dns/message_test.c.", " - CVE-2026-75029", " * SECURITY UPDATE: Unexpected exit with DNS64 and malformed answers", " - debian/patches/CVE-2026-19666-1.patch: Clear the noqname alias on the", " DNS64 filter64 path in lib/ns/query.c.", " - debian/patches/CVE-2026-19666-2.patch: Test the DNS64 filter64 path", " against a cached NOQNAME proof in bin/tests/system/dns64/ns1/example.db,", " bin/tests/system/dns64/ns2/named.conf.in, bin/tests/system/dns64/tests.sh.", " - CVE-2026-19666", " * SECURITY UPDATE: Unexpected exit via use-after-free with cached DNSSEC", " proofs", " - debian/patches/CVE-2026-19662-pre1.patch: Remove unused closest encloser", " proof caching in lib/dns/dnsrps.c, lib/dns/include/dns/rdataset.h,", " lib/dns/keytable.c, lib/dns/ncache.c, lib/dns/rbtdb.c,", " lib/dns/rdatalist.c, lib/dns/rdatalist_p.h, lib/dns/rdataset.c,", " lib/dns/resolver.c, lib/dns/sdb.c, lib/dns/sdlz.c, lib/ns/query.c.", " - debian/patches/CVE-2026-19662-1.patch: Keep NOQNAME proof slabheaders", " alive in lib/dns/rbtdb.c.", " - debian/patches/CVE-2026-19662-2.patch: Test NOQNAME proof slabheader", " lifetime in tests/dns/rbtdb_test.c.", " - CVE-2026-19662", " * SECURITY UPDATE: Forged NXDOMAIN via inapplicable NSEC wildcard proof", " - debian/patches/CVE-2026-19941-1.patch: Require NSEC wildcard proofs from", " the same zone in lib/dns/include/dns/validator.h, lib/dns/validator.c.", " - debian/patches/CVE-2026-19941-2.patch: Test rejection of cross-zone NSEC", " wildcard proofs in bin/tests/system/Makefile.am,", " bin/tests/system/conf.sh.common,", " bin/tests/system/nsec_wildcard_wrong_zone/ans1/ans.py,", " bin/tests/system/nsec_wildcard_wrong_zone/ns2/named.conf.j2, bin/tests/sys", " tem/nsec_wildcard_wrong_zone/tests_nsec_wildcard_wrong_zone.py.", " - CVE-2026-19941", " * SECURITY UPDATE: Out-of-zone records served as authoritative", " - debian/patches/CVE-2026-78301-1.patch: Test that nodes above the zone apex", " are not zone cuts in bin/tests/system/outofzone_zonecut/ns1/attacker.db,", " bin/tests/system/outofzone_zonecut/ns1/example.db,", " bin/tests/system/outofzone_zonecut/ns1/named.conf.j2,", " bin/tests/system/outofzone_zonecut/ns1/root.db,", " bin/tests/system/outofzone_zonecut/ns2/dnamezone.db,", " bin/tests/system/outofzone_zonecut/ns2/named.conf.j2,", " bin/tests/system/outofzone_zonecut/ns2/nszone.db,", " bin/tests/system/outofzone_zonecut/ns3/dnamezone.db,", " bin/tests/system/outofzone_zonecut/ns3/named.conf.j2,", " bin/tests/system/outofzone_zonecut/ns3/nszone.db,", " bin/tests/system/outofzone_zonecut/tests_outofzone_zonecut.py.", " - debian/patches/CVE-2026-78301-2.patch: Ignore nodes above the zone origin", " in RBT zone database lookups in lib/dns/rbtdb.c, tests/dns/rbtdb_test.c.", " - CVE-2026-78301", " * SECURITY UPDATE: Resource exhaustion via HTTPS/SVCB AliasMode records", " - debian/patches/CVE-2026-81563-1.patch: Add a system test for HTTPS", " AliasMode additional-data errors in", " bin/tests/system/additional/ns1/https.db,", " bin/tests/system/additional/ns1/named1.conf.in,", " bin/tests/system/additional/ns1/named2.conf.in,", " bin/tests/system/additional/ns1/named3.conf.in,", " bin/tests/system/additional/ns1/named4.conf.in,", " bin/tests/system/additional/ns2/root.db,", " bin/tests/system/additional/ns3/named.conf.in,", " bin/tests/system/additional/tests_https_alias.py.", " - debian/patches/CVE-2026-81563-2.patch: Release the rdataset when SVCB", " additional-data lookups fail in lib/dns/rdata/in_1/svcb_64.c.", " - CVE-2026-81563", " * SECURITY UPDATE: DNSSEC downgrade via NSEC3 from an unrelated sibling zone", " - debian/patches/CVE-2026-77119-2.patch: Reject out-of-zone NSEC3 in the", " insecure-referral proof in lib/dns/validator.c.", " - CVE-2026-77119", " * SECURITY UPDATE: Unexpected exit on wildcard answers with NSEC and NSEC3", " proofs", " - debian/patches/CVE-2026-80274-1.patch: Keep NOQNAME proof selection", " consistent in lib/dns/include/dns/rdataset.h,", " lib/dns/include/dns/validator.h, lib/dns/rdatalist.c,", " lib/dns/rdatalist_p.h, lib/dns/rdataset.c, lib/dns/resolver.c,", " lib/dns/validator.c, tests/dns/rbtdb_test.c.", " - debian/patches/CVE-2026-80274-2.patch: Test NOQNAME proof selection in the", " rdataset unit test in tests/dns/rdataset_test.c.", " - debian/patches/CVE-2026-80274-3.patch: Make the findnoqname mismatch", " system test reach the resolver in", " bin/tests/system/dnssec_findnoqname_mismatch/ans1/ans.py, bin/tests/system", " /dnssec_findnoqname_mismatch/tests_findnoqname_mismatch.py.", " - CVE-2026-80274", " * SECURITY UPDATE: Zone transfer data used before TSIG verification", " - debian/patches/CVE-2026-19033.patch: Remove support for sparse TSIG in", " lib/dns/xfrin.c.", " - CVE-2026-19033", " * SECURITY UPDATE: Excessive CPU usage via cached HTTPS/SVCB AliasMode records", " - debian/patches/CVE-2026-81736-1.patch: Bound the total additional", " processing for a single query in lib/ns/client.c,", " lib/ns/include/ns/client.h, lib/ns/query.c.", " - debian/patches/CVE-2026-81736-2.patch: Add a system test for SVCB/HTTPS", " AliasMode additional processing in", " bin/tests/system/additional/ns1/https.db,", " bin/tests/system/additional/tests_https_alias.py,", " bin/tests/system/svcb_alias/ns1/named.conf.j2,", " bin/tests/system/svcb_alias/ns1/root.hint,", " bin/tests/system/svcb_alias/ns2/named.conf.j2,", " bin/tests/system/svcb_alias/ns2/root.db,", " bin/tests/system/svcb_alias/setup.sh,", " bin/tests/system/svcb_alias/tests_svcb_alias.py.", " - CVE-2026-81736", " * SECURITY UPDATE: Unexpected exit via oversized negative cache records", " - debian/patches/CVE-2026-19667-1.patch: Reject negative cache records that", " do not fit in a dns_rdata_t in lib/dns/ncache.c.", " - debian/patches/CVE-2026-19667-2.patch: Test that an oversized negative", " cache record is rejected in tests/dns/Makefile.am,", " tests/dns/ncache_test.c.", " - CVE-2026-19667", "" ], "package": "bind9", "version": "1:9.18.39-0ubuntu0.24.04.8", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "John Breton ", "date": "Fri, 09 Oct 2026 12:07:30 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "curl", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.15", "version": "8.5.0-2ubuntu10.15" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.16", "version": "8.5.0-2ubuntu10.16" }, "cves": [ { "cve": "CVE-2026-86409", "url": "https://ubuntu.com/security/CVE-2026-86409", "cve_description": "Setting `CURLOPT_AWS_SIGV4` to NULL does not disable SigV4 authentication, contrary to expectations and documentation. A subsequent transfer on the same handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL is set next, leaking state information.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-86414", "url": "https://ubuntu.com/security/CVE-2026-86414", "cve_description": "A HTTP proxy can trick libcurl into sending the origin's credentials (Basic password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the expected 407 `Proxy-Authenticate:`.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87862", "url": "https://ubuntu.com/security/CVE-2026-87862", "cve_description": "Importing a `includeSubDomains` parent HSTS entry before a longer-lived child entry, silently drops the child. Consequently, when the parent expires, the child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP requests rather than upgrading to HTTPS.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87863", "url": "https://ubuntu.com/security/CVE-2026-87863", "cve_description": "An authenticated HTTPS origin can supply an HSTS `max-age` value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87864", "url": "https://ubuntu.com/security/CVE-2026-87864", "cve_description": "Enabling `CURLOPT_CRLF` causes curl to advertise the raw input byte count in the `IMAP APPEND {N}` literal while transmitting line-ending expanded data. The server reads only N bytes for the payload, causing the remaining overflow bytes to be interpreted and executed as pipelined IMAP commands within the authenticated session.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92388", "url": "https://ubuntu.com/security/CVE-2026-92388", "cve_description": "When an FTP wildcard `LIST` operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via `curl_easy_duphandle()` copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read against the dangling handle reference; alternatively, reusing the original or cloned handle while reconfiguring only `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`) results in type confusion, forcing the internal parser to interpret incoming server response bytes into memory at the application-supplied write data pointer.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92389", "url": "https://ubuntu.com/security/CVE-2026-92389", "cve_description": "libcurl's TFTP state machine fails to validate state transitions against the requested transfer direction, accepting opening server responses for both reads and writes interchangeably. A malicious TFTP server can respond to a download request in a way that forces the client into transmit mode, prompting libcurl to consume and transmit data from the handle's persistent `CURLOPT_READDATA` pointer - including data remaining from unrelated prior operations, such as an HTTP POST request executed on a reused handle.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92391", "url": "https://ubuntu.com/security/CVE-2026-92391", "cve_description": "A deeply nested multipart MIME structure constructed via the public API causes a stack overflow in libcurl during normal cleanup operations. An excessive recursion depth within `curl_mime_free` leads to unbounded stack frame allocation during structure traversal, ultimately crashing the host process.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-94266", "url": "https://ubuntu.com/security/CVE-2026-94266", "cve_description": "libcurl could accidentally return a URL for curl_easy_getinfo's `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did. The curl tool exposes the same information using the command line option `--write-out '%{url_effective}'`. This credential leak can happen when curl retrieves credentials from a `.netrc` file.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-86409", "url": "https://ubuntu.com/security/CVE-2026-86409", "cve_description": "Setting `CURLOPT_AWS_SIGV4` to NULL does not disable SigV4 authentication, contrary to expectations and documentation. A subsequent transfer on the same handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL is set next, leaking state information.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-86414", "url": "https://ubuntu.com/security/CVE-2026-86414", "cve_description": "A HTTP proxy can trick libcurl into sending the origin's credentials (Basic password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the expected 407 `Proxy-Authenticate:`.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87862", "url": "https://ubuntu.com/security/CVE-2026-87862", "cve_description": "Importing a `includeSubDomains` parent HSTS entry before a longer-lived child entry, silently drops the child. Consequently, when the parent expires, the child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP requests rather than upgrading to HTTPS.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87863", "url": "https://ubuntu.com/security/CVE-2026-87863", "cve_description": "An authenticated HTTPS origin can supply an HSTS `max-age` value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87864", "url": "https://ubuntu.com/security/CVE-2026-87864", "cve_description": "Enabling `CURLOPT_CRLF` causes curl to advertise the raw input byte count in the `IMAP APPEND {N}` literal while transmitting line-ending expanded data. The server reads only N bytes for the payload, causing the remaining overflow bytes to be interpreted and executed as pipelined IMAP commands within the authenticated session.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92388", "url": "https://ubuntu.com/security/CVE-2026-92388", "cve_description": "When an FTP wildcard `LIST` operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via `curl_easy_duphandle()` copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read against the dangling handle reference; alternatively, reusing the original or cloned handle while reconfiguring only `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`) results in type confusion, forcing the internal parser to interpret incoming server response bytes into memory at the application-supplied write data pointer.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92389", "url": "https://ubuntu.com/security/CVE-2026-92389", "cve_description": "libcurl's TFTP state machine fails to validate state transitions against the requested transfer direction, accepting opening server responses for both reads and writes interchangeably. A malicious TFTP server can respond to a download request in a way that forces the client into transmit mode, prompting libcurl to consume and transmit data from the handle's persistent `CURLOPT_READDATA` pointer - including data remaining from unrelated prior operations, such as an HTTP POST request executed on a reused handle.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92391", "url": "https://ubuntu.com/security/CVE-2026-92391", "cve_description": "A deeply nested multipart MIME structure constructed via the public API causes a stack overflow in libcurl during normal cleanup operations. An excessive recursion depth within `curl_mime_free` leads to unbounded stack frame allocation during structure traversal, ultimately crashing the host process.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-94266", "url": "https://ubuntu.com/security/CVE-2026-94266", "cve_description": "libcurl could accidentally return a URL for curl_easy_getinfo's `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did. The curl tool exposes the same information using the command line option `--write-out '%{url_effective}'`. This credential leak can happen when curl retrieves credentials from a `.netrc` file.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Information exposure from stale AWS SigV4 authentication.", " - debian/patches/CVE-2026-86409.patch: clear CURLAUTH_AWS_SIGV4 when", " CURLOPT_AWS_SIGV4 is set to NULL in lib/setopt.c.", " - CVE-2026-86409", " * SECURITY UPDATE: Credential exposure to an HTTP proxy in CONNECT.", " - debian/patches/CVE-2026-86414.patch: do not react to 401 responses to a", " CONNECT request in lib/cf-h1-proxy.c, lib/cf-h2-proxy.c.", " - CVE-2026-86414", " * SECURITY UPDATE: Improper handling of HSTS entries on load.", " - debian/patches/CVE-2026-87862.patch: match only the exact host, not", " parent domains, when removing duplicates while loading an HSTS file in", " lib/hsts.c.", " - CVE-2026-87862", " * SECURITY UPDATE: Data loss from out-of-range HSTS max-age.", " - debian/patches/CVE-2026-87863.patch: cap max-age to two years and skip", " entries whose expiry cannot be formatted in lib/hsts.c.", " - CVE-2026-87863", " * SECURITY UPDATE: Command injection in IMAP APPEND with CURLOPT_CRLF.", " - debian/patches/CVE-2026-87864.patch: reject APPEND when CRLF conversion", " is enabled, as it makes the upload size unknown in lib/imap.c.", " - CVE-2026-87864", " * SECURITY UPDATE: Use after free in FTP wildcard matching.", " - debian/patches/CVE-2026-92388-1.patch: stop overwriting set.write_func", " and set.out in lib/sendf.c, lib/ftp.h, lib/ftp.c, lib/ftplistparser.c,", " lib/ftplistparser.h.", " - debian/patches/CVE-2026-92388-2.patch: only use the list parser in the", " CURLWC_MATCHING state in lib/ftplistparser.c.", " - CVE-2026-92388", " * SECURITY UPDATE: Information exposure from TFTP transfer direction", " confusion.", " - debian/patches/CVE-2026-92389.patch: return CURLE_TFTP_ILLEGAL when a", " server response does not match the transfer direction in lib/tftp.c.", " - CVE-2026-92389", " * SECURITY UPDATE: Stack overflow from deeply nested MIME structures.", " - debian/patches/CVE-2026-92391.patch: free MIME handles non-recursively in", " curl_mime_free in lib/mime.c.", " - CVE-2026-92391", " * SECURITY UPDATE: Credential exposure in CURLINFO_EFFECTIVE_URL.", " - debian/patches/CVE-2026-94266.patch: return a copy of the URL without", " credentials for CURLINFO_EFFECTIVE_URL in lib/getinfo.c, lib/transfer.c,", " lib/url.c, lib/urldata.h.", " - CVE-2026-94266", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Charles Cochran ", "date": "Mon, 12 Oct 2026 18:12:33 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "dracut-install", "from_version": { "source_package_name": "dracut", "source_package_version": "060+5-1ubuntu3.3", "version": "060+5-1ubuntu3.3" }, "to_version": { "source_package_name": "dracut", "source_package_version": "060+5-1ubuntu3.4", "version": "060+5-1ubuntu3.4" }, "cves": [ { "cve": "CVE-2026-15816", "url": "https://ubuntu.com/security/CVE-2026-15816", "cve_description": "A flaw was found in dracut. The die() error-handling function writes its message into a shell script under the initramfs emergency-hook directory without properly shell-quoting it. When the message contains data derived from the DHCP ROOT_PATH option, an attacker on the adjacent network who controls a rogue DHCP server can inject a command-substitution sequence that executes as root the next time dracut sources its emergency hook scripts during standard boot-failure handling.", "cve_priority": "medium", "cve_public_date": "2026-08-07 11:17:00 UTC" }, { "cve": "CVE-2026-6893", "url": "https://ubuntu.com/security/CVE-2026-6893", "cve_description": "A flaw was found in dracut. A remote attacker on the adjacent network can exploit this vulnerability by providing specially crafted DHCP (Dynamic Host Configuration Protocol) options, such as a malicious hostname, to a system using dracut's legacy DHCP path. These options are improperly handled and written into temporary shell scripts without proper escaping, leading to command injection. This allows the attacker to achieve root code execution within the initramfs, potentially compromising the system's boot and network behavior.", "cve_priority": "medium", "cve_public_date": "2026-06-10 20:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-15816", "url": "https://ubuntu.com/security/CVE-2026-15816", "cve_description": "A flaw was found in dracut. The die() error-handling function writes its message into a shell script under the initramfs emergency-hook directory without properly shell-quoting it. When the message contains data derived from the DHCP ROOT_PATH option, an attacker on the adjacent network who controls a rogue DHCP server can inject a command-substitution sequence that executes as root the next time dracut sources its emergency hook scripts during standard boot-failure handling.", "cve_priority": "medium", "cve_public_date": "2026-08-07 11:17:00 UTC" }, { "cve": "CVE-2026-6893", "url": "https://ubuntu.com/security/CVE-2026-6893", "cve_description": "A flaw was found in dracut. A remote attacker on the adjacent network can exploit this vulnerability by providing specially crafted DHCP (Dynamic Host Configuration Protocol) options, such as a malicious hostname, to a system using dracut's legacy DHCP path. These options are improperly handled and written into temporary shell scripts without proper escaping, leading to command injection. This allows the attacker to achieve root code execution within the initramfs, potentially compromising the system's boot and network behavior.", "cve_priority": "medium", "cve_public_date": "2026-06-10 20:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Remote Code Execution", " - debian/patches/CVE-2026-15816-1.patch: feat(base): add escape function", " implementing printf %q in modules.d/99base/dracut-lib.sh.", " - debian/patches/CVE-2026-15816-2.patch: fix(base): sanitize message written", " by die() to the emergency hook in modules.d/99base/dracut-lib.sh.", " - CVE-2026-15816", " * SECURITY UPDATE: Remote Code Execution", " - debian/patches/CVE-2026-6893-1.patch: fix(network-legacy): sanitize DHCP", " values in dhclient-script.sh in modules.d/35network-legacy/dhclient-", " script.sh.", " - debian/patches/CVE-2026-6893-2.patch: fix(network-legacy): strip DHCP-", " supplied domain to a safe charset in modules.d/35network-legacy/dhclient-", " script.sh.", " - CVE-2026-6893", "" ], "package": "dracut", "version": "060+5-1ubuntu3.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "John Breton ", "date": "Thu, 24 Sep 2026 13:28:12 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libapparmor1:s390x", "from_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.8", "version": "4.0.1really4.0.1-0ubuntu0.24.04.8" }, "to_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.9", "version": "4.0.1really4.0.1-0ubuntu0.24.04.9" }, "cves": [], "launchpad_bugs_fixed": [ 2083548 ], "changes": [ { "cves": [], "log": [ "", " * Fix transmission-daemon timeout inside systemd confinement. (LP: #2083548)", "" ], "package": "apparmor", "version": "4.0.1really4.0.1-0ubuntu0.24.04.9", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2083548 ], "author": "Willow Carlson-Huber ", "date": "Fri, 18 Sep 2026 12:52:55 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "libarchive13t64:s390x", "from_version": { "source_package_name": "libarchive", "source_package_version": "3.7.2-2ubuntu0.8", "version": "3.7.2-2ubuntu0.8" }, "to_version": { "source_package_name": "libarchive", "source_package_version": "3.7.2-2ubuntu0.9", "version": "3.7.2-2ubuntu0.9" }, "cves": [ { "cve": "CVE-2026-16517", "url": "https://ubuntu.com/security/CVE-2026-16517", "cve_description": "A signed integer overflow vulnerability was found in libarchive's ZIP writer. In the archive_write_zip_header function in archive_write_set_format_zip.c, when ZIP encryption is enabled and the entry file size is close to INT64_MAX, the addition of the encryption overhead to the entry size overflows int64_t, resulting in undefined behavior. This could lead to incorrect Zip64 extension decisions or potential memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-07-21 23:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-16517", "url": "https://ubuntu.com/security/CVE-2026-16517", "cve_description": "A signed integer overflow vulnerability was found in libarchive's ZIP writer. In the archive_write_zip_header function in archive_write_set_format_zip.c, when ZIP encryption is enabled and the entry file size is close to INT64_MAX, the addition of the encryption overhead to the entry size overflows int64_t, resulting in undefined behavior. This could lead to incorrect Zip64 extension decisions or potential memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-07-21 23:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: integer overflow in ZIP writer", " - debian/patches/CVE-2026-16517.patch: Merge pull request #3228 from", " datauwu/zip-encrypted-int-overflow in", " libarchive/archive_write_set_format_zip.c.", " - CVE-2026-16517", "" ], "package": "libarchive", "version": "3.7.2-2ubuntu0.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 07 Oct 2026 09:41:12 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcurl3t64-gnutls:s390x", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.15", "version": "8.5.0-2ubuntu10.15" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.16", "version": "8.5.0-2ubuntu10.16" }, "cves": [ { "cve": "CVE-2026-86409", "url": "https://ubuntu.com/security/CVE-2026-86409", "cve_description": "Setting `CURLOPT_AWS_SIGV4` to NULL does not disable SigV4 authentication, contrary to expectations and documentation. A subsequent transfer on the same handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL is set next, leaking state information.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-86414", "url": "https://ubuntu.com/security/CVE-2026-86414", "cve_description": "A HTTP proxy can trick libcurl into sending the origin's credentials (Basic password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the expected 407 `Proxy-Authenticate:`.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87862", "url": "https://ubuntu.com/security/CVE-2026-87862", "cve_description": "Importing a `includeSubDomains` parent HSTS entry before a longer-lived child entry, silently drops the child. Consequently, when the parent expires, the child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP requests rather than upgrading to HTTPS.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87863", "url": "https://ubuntu.com/security/CVE-2026-87863", "cve_description": "An authenticated HTTPS origin can supply an HSTS `max-age` value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87864", "url": "https://ubuntu.com/security/CVE-2026-87864", "cve_description": "Enabling `CURLOPT_CRLF` causes curl to advertise the raw input byte count in the `IMAP APPEND {N}` literal while transmitting line-ending expanded data. The server reads only N bytes for the payload, causing the remaining overflow bytes to be interpreted and executed as pipelined IMAP commands within the authenticated session.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92388", "url": "https://ubuntu.com/security/CVE-2026-92388", "cve_description": "When an FTP wildcard `LIST` operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via `curl_easy_duphandle()` copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read against the dangling handle reference; alternatively, reusing the original or cloned handle while reconfiguring only `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`) results in type confusion, forcing the internal parser to interpret incoming server response bytes into memory at the application-supplied write data pointer.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92389", "url": "https://ubuntu.com/security/CVE-2026-92389", "cve_description": "libcurl's TFTP state machine fails to validate state transitions against the requested transfer direction, accepting opening server responses for both reads and writes interchangeably. A malicious TFTP server can respond to a download request in a way that forces the client into transmit mode, prompting libcurl to consume and transmit data from the handle's persistent `CURLOPT_READDATA` pointer - including data remaining from unrelated prior operations, such as an HTTP POST request executed on a reused handle.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92391", "url": "https://ubuntu.com/security/CVE-2026-92391", "cve_description": "A deeply nested multipart MIME structure constructed via the public API causes a stack overflow in libcurl during normal cleanup operations. An excessive recursion depth within `curl_mime_free` leads to unbounded stack frame allocation during structure traversal, ultimately crashing the host process.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-94266", "url": "https://ubuntu.com/security/CVE-2026-94266", "cve_description": "libcurl could accidentally return a URL for curl_easy_getinfo's `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did. The curl tool exposes the same information using the command line option `--write-out '%{url_effective}'`. This credential leak can happen when curl retrieves credentials from a `.netrc` file.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-86409", "url": "https://ubuntu.com/security/CVE-2026-86409", "cve_description": "Setting `CURLOPT_AWS_SIGV4` to NULL does not disable SigV4 authentication, contrary to expectations and documentation. A subsequent transfer on the same handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL is set next, leaking state information.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-86414", "url": "https://ubuntu.com/security/CVE-2026-86414", "cve_description": "A HTTP proxy can trick libcurl into sending the origin's credentials (Basic password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the expected 407 `Proxy-Authenticate:`.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87862", "url": "https://ubuntu.com/security/CVE-2026-87862", "cve_description": "Importing a `includeSubDomains` parent HSTS entry before a longer-lived child entry, silently drops the child. Consequently, when the parent expires, the child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP requests rather than upgrading to HTTPS.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87863", "url": "https://ubuntu.com/security/CVE-2026-87863", "cve_description": "An authenticated HTTPS origin can supply an HSTS `max-age` value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87864", "url": "https://ubuntu.com/security/CVE-2026-87864", "cve_description": "Enabling `CURLOPT_CRLF` causes curl to advertise the raw input byte count in the `IMAP APPEND {N}` literal while transmitting line-ending expanded data. The server reads only N bytes for the payload, causing the remaining overflow bytes to be interpreted and executed as pipelined IMAP commands within the authenticated session.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92388", "url": "https://ubuntu.com/security/CVE-2026-92388", "cve_description": "When an FTP wildcard `LIST` operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via `curl_easy_duphandle()` copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read against the dangling handle reference; alternatively, reusing the original or cloned handle while reconfiguring only `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`) results in type confusion, forcing the internal parser to interpret incoming server response bytes into memory at the application-supplied write data pointer.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92389", "url": "https://ubuntu.com/security/CVE-2026-92389", "cve_description": "libcurl's TFTP state machine fails to validate state transitions against the requested transfer direction, accepting opening server responses for both reads and writes interchangeably. A malicious TFTP server can respond to a download request in a way that forces the client into transmit mode, prompting libcurl to consume and transmit data from the handle's persistent `CURLOPT_READDATA` pointer - including data remaining from unrelated prior operations, such as an HTTP POST request executed on a reused handle.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92391", "url": "https://ubuntu.com/security/CVE-2026-92391", "cve_description": "A deeply nested multipart MIME structure constructed via the public API causes a stack overflow in libcurl during normal cleanup operations. An excessive recursion depth within `curl_mime_free` leads to unbounded stack frame allocation during structure traversal, ultimately crashing the host process.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-94266", "url": "https://ubuntu.com/security/CVE-2026-94266", "cve_description": "libcurl could accidentally return a URL for curl_easy_getinfo's `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did. The curl tool exposes the same information using the command line option `--write-out '%{url_effective}'`. This credential leak can happen when curl retrieves credentials from a `.netrc` file.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Information exposure from stale AWS SigV4 authentication.", " - debian/patches/CVE-2026-86409.patch: clear CURLAUTH_AWS_SIGV4 when", " CURLOPT_AWS_SIGV4 is set to NULL in lib/setopt.c.", " - CVE-2026-86409", " * SECURITY UPDATE: Credential exposure to an HTTP proxy in CONNECT.", " - debian/patches/CVE-2026-86414.patch: do not react to 401 responses to a", " CONNECT request in lib/cf-h1-proxy.c, lib/cf-h2-proxy.c.", " - CVE-2026-86414", " * SECURITY UPDATE: Improper handling of HSTS entries on load.", " - debian/patches/CVE-2026-87862.patch: match only the exact host, not", " parent domains, when removing duplicates while loading an HSTS file in", " lib/hsts.c.", " - CVE-2026-87862", " * SECURITY UPDATE: Data loss from out-of-range HSTS max-age.", " - debian/patches/CVE-2026-87863.patch: cap max-age to two years and skip", " entries whose expiry cannot be formatted in lib/hsts.c.", " - CVE-2026-87863", " * SECURITY UPDATE: Command injection in IMAP APPEND with CURLOPT_CRLF.", " - debian/patches/CVE-2026-87864.patch: reject APPEND when CRLF conversion", " is enabled, as it makes the upload size unknown in lib/imap.c.", " - CVE-2026-87864", " * SECURITY UPDATE: Use after free in FTP wildcard matching.", " - debian/patches/CVE-2026-92388-1.patch: stop overwriting set.write_func", " and set.out in lib/sendf.c, lib/ftp.h, lib/ftp.c, lib/ftplistparser.c,", " lib/ftplistparser.h.", " - debian/patches/CVE-2026-92388-2.patch: only use the list parser in the", " CURLWC_MATCHING state in lib/ftplistparser.c.", " - CVE-2026-92388", " * SECURITY UPDATE: Information exposure from TFTP transfer direction", " confusion.", " - debian/patches/CVE-2026-92389.patch: return CURLE_TFTP_ILLEGAL when a", " server response does not match the transfer direction in lib/tftp.c.", " - CVE-2026-92389", " * SECURITY UPDATE: Stack overflow from deeply nested MIME structures.", " - debian/patches/CVE-2026-92391.patch: free MIME handles non-recursively in", " curl_mime_free in lib/mime.c.", " - CVE-2026-92391", " * SECURITY UPDATE: Credential exposure in CURLINFO_EFFECTIVE_URL.", " - debian/patches/CVE-2026-94266.patch: return a copy of the URL without", " credentials for CURLINFO_EFFECTIVE_URL in lib/getinfo.c, lib/transfer.c,", " lib/url.c, lib/urldata.h.", " - CVE-2026-94266", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Charles Cochran ", "date": "Mon, 12 Oct 2026 18:12:33 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcurl4t64:s390x", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.15", "version": "8.5.0-2ubuntu10.15" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.16", "version": "8.5.0-2ubuntu10.16" }, "cves": [ { "cve": "CVE-2026-86409", "url": "https://ubuntu.com/security/CVE-2026-86409", "cve_description": "Setting `CURLOPT_AWS_SIGV4` to NULL does not disable SigV4 authentication, contrary to expectations and documentation. A subsequent transfer on the same handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL is set next, leaking state information.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-86414", "url": "https://ubuntu.com/security/CVE-2026-86414", "cve_description": "A HTTP proxy can trick libcurl into sending the origin's credentials (Basic password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the expected 407 `Proxy-Authenticate:`.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87862", "url": "https://ubuntu.com/security/CVE-2026-87862", "cve_description": "Importing a `includeSubDomains` parent HSTS entry before a longer-lived child entry, silently drops the child. Consequently, when the parent expires, the child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP requests rather than upgrading to HTTPS.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87863", "url": "https://ubuntu.com/security/CVE-2026-87863", "cve_description": "An authenticated HTTPS origin can supply an HSTS `max-age` value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87864", "url": "https://ubuntu.com/security/CVE-2026-87864", "cve_description": "Enabling `CURLOPT_CRLF` causes curl to advertise the raw input byte count in the `IMAP APPEND {N}` literal while transmitting line-ending expanded data. The server reads only N bytes for the payload, causing the remaining overflow bytes to be interpreted and executed as pipelined IMAP commands within the authenticated session.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92388", "url": "https://ubuntu.com/security/CVE-2026-92388", "cve_description": "When an FTP wildcard `LIST` operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via `curl_easy_duphandle()` copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read against the dangling handle reference; alternatively, reusing the original or cloned handle while reconfiguring only `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`) results in type confusion, forcing the internal parser to interpret incoming server response bytes into memory at the application-supplied write data pointer.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92389", "url": "https://ubuntu.com/security/CVE-2026-92389", "cve_description": "libcurl's TFTP state machine fails to validate state transitions against the requested transfer direction, accepting opening server responses for both reads and writes interchangeably. A malicious TFTP server can respond to a download request in a way that forces the client into transmit mode, prompting libcurl to consume and transmit data from the handle's persistent `CURLOPT_READDATA` pointer - including data remaining from unrelated prior operations, such as an HTTP POST request executed on a reused handle.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92391", "url": "https://ubuntu.com/security/CVE-2026-92391", "cve_description": "A deeply nested multipart MIME structure constructed via the public API causes a stack overflow in libcurl during normal cleanup operations. An excessive recursion depth within `curl_mime_free` leads to unbounded stack frame allocation during structure traversal, ultimately crashing the host process.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-94266", "url": "https://ubuntu.com/security/CVE-2026-94266", "cve_description": "libcurl could accidentally return a URL for curl_easy_getinfo's `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did. The curl tool exposes the same information using the command line option `--write-out '%{url_effective}'`. This credential leak can happen when curl retrieves credentials from a `.netrc` file.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-86409", "url": "https://ubuntu.com/security/CVE-2026-86409", "cve_description": "Setting `CURLOPT_AWS_SIGV4` to NULL does not disable SigV4 authentication, contrary to expectations and documentation. A subsequent transfer on the same handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL is set next, leaking state information.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-86414", "url": "https://ubuntu.com/security/CVE-2026-86414", "cve_description": "A HTTP proxy can trick libcurl into sending the origin's credentials (Basic password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the expected 407 `Proxy-Authenticate:`.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87862", "url": "https://ubuntu.com/security/CVE-2026-87862", "cve_description": "Importing a `includeSubDomains` parent HSTS entry before a longer-lived child entry, silently drops the child. Consequently, when the parent expires, the child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP requests rather than upgrading to HTTPS.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87863", "url": "https://ubuntu.com/security/CVE-2026-87863", "cve_description": "An authenticated HTTPS origin can supply an HSTS `max-age` value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87864", "url": "https://ubuntu.com/security/CVE-2026-87864", "cve_description": "Enabling `CURLOPT_CRLF` causes curl to advertise the raw input byte count in the `IMAP APPEND {N}` literal while transmitting line-ending expanded data. The server reads only N bytes for the payload, causing the remaining overflow bytes to be interpreted and executed as pipelined IMAP commands within the authenticated session.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92388", "url": "https://ubuntu.com/security/CVE-2026-92388", "cve_description": "When an FTP wildcard `LIST` operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via `curl_easy_duphandle()` copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read against the dangling handle reference; alternatively, reusing the original or cloned handle while reconfiguring only `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`) results in type confusion, forcing the internal parser to interpret incoming server response bytes into memory at the application-supplied write data pointer.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92389", "url": "https://ubuntu.com/security/CVE-2026-92389", "cve_description": "libcurl's TFTP state machine fails to validate state transitions against the requested transfer direction, accepting opening server responses for both reads and writes interchangeably. A malicious TFTP server can respond to a download request in a way that forces the client into transmit mode, prompting libcurl to consume and transmit data from the handle's persistent `CURLOPT_READDATA` pointer - including data remaining from unrelated prior operations, such as an HTTP POST request executed on a reused handle.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92391", "url": "https://ubuntu.com/security/CVE-2026-92391", "cve_description": "A deeply nested multipart MIME structure constructed via the public API causes a stack overflow in libcurl during normal cleanup operations. An excessive recursion depth within `curl_mime_free` leads to unbounded stack frame allocation during structure traversal, ultimately crashing the host process.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-94266", "url": "https://ubuntu.com/security/CVE-2026-94266", "cve_description": "libcurl could accidentally return a URL for curl_easy_getinfo's `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did. The curl tool exposes the same information using the command line option `--write-out '%{url_effective}'`. This credential leak can happen when curl retrieves credentials from a `.netrc` file.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Information exposure from stale AWS SigV4 authentication.", " - debian/patches/CVE-2026-86409.patch: clear CURLAUTH_AWS_SIGV4 when", " CURLOPT_AWS_SIGV4 is set to NULL in lib/setopt.c.", " - CVE-2026-86409", " * SECURITY UPDATE: Credential exposure to an HTTP proxy in CONNECT.", " - debian/patches/CVE-2026-86414.patch: do not react to 401 responses to a", " CONNECT request in lib/cf-h1-proxy.c, lib/cf-h2-proxy.c.", " - CVE-2026-86414", " * SECURITY UPDATE: Improper handling of HSTS entries on load.", " - debian/patches/CVE-2026-87862.patch: match only the exact host, not", " parent domains, when removing duplicates while loading an HSTS file in", " lib/hsts.c.", " - CVE-2026-87862", " * SECURITY UPDATE: Data loss from out-of-range HSTS max-age.", " - debian/patches/CVE-2026-87863.patch: cap max-age to two years and skip", " entries whose expiry cannot be formatted in lib/hsts.c.", " - CVE-2026-87863", " * SECURITY UPDATE: Command injection in IMAP APPEND with CURLOPT_CRLF.", " - debian/patches/CVE-2026-87864.patch: reject APPEND when CRLF conversion", " is enabled, as it makes the upload size unknown in lib/imap.c.", " - CVE-2026-87864", " * SECURITY UPDATE: Use after free in FTP wildcard matching.", " - debian/patches/CVE-2026-92388-1.patch: stop overwriting set.write_func", " and set.out in lib/sendf.c, lib/ftp.h, lib/ftp.c, lib/ftplistparser.c,", " lib/ftplistparser.h.", " - debian/patches/CVE-2026-92388-2.patch: only use the list parser in the", " CURLWC_MATCHING state in lib/ftplistparser.c.", " - CVE-2026-92388", " * SECURITY UPDATE: Information exposure from TFTP transfer direction", " confusion.", " - debian/patches/CVE-2026-92389.patch: return CURLE_TFTP_ILLEGAL when a", " server response does not match the transfer direction in lib/tftp.c.", " - CVE-2026-92389", " * SECURITY UPDATE: Stack overflow from deeply nested MIME structures.", " - debian/patches/CVE-2026-92391.patch: free MIME handles non-recursively in", " curl_mime_free in lib/mime.c.", " - CVE-2026-92391", " * SECURITY UPDATE: Credential exposure in CURLINFO_EFFECTIVE_URL.", " - debian/patches/CVE-2026-94266.patch: return a copy of the URL without", " credentials for CURLINFO_EFFECTIVE_URL in lib/getinfo.c, lib/transfer.c,", " lib/url.c, lib/urldata.h.", " - CVE-2026-94266", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Charles Cochran ", "date": "Mon, 12 Oct 2026 18:12:33 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libevent-core-2.1-7t64:s390x", "from_version": { "source_package_name": "libevent", "source_package_version": "2.1.12-stable-9ubuntu2.1", "version": "2.1.12-stable-9ubuntu2.1" }, "to_version": { "source_package_name": "libevent", "source_package_version": "2.1.12-stable-9ubuntu2.2", "version": "2.1.12-stable-9ubuntu2.2" }, "cves": [ { "cve": "CVE-2026-63387", "url": "https://ubuntu.com/security/CVE-2026-63387", "cve_description": "Libevent is an event notification library. Prior to 2.1.13 and 2.2.2-alpha, libevent has an off-by-one stack buffer overflow in evdns.c when dnsname_to_labels formats a name-bearing DNS record at the end of the 64 KB stack buffer allocated by evdns_server_request_format_response. The final-label check permits j plus label_len plus one to equal buf_len, after which the terminating null byte is written to buf[buf_len]. A crafted DNS server response containing PTR, CNAME, MX, NS, or SOA data can trigger the one-byte out-of-bounds write and crash or corrupt the process. This issue is fixed in versions 2.1.13 and 2.2.2-alpha.", "cve_priority": "medium", "cve_public_date": "2026-08-20 18:16:00 UTC" }, { "cve": "CVE-2026-63388", "url": "https://ubuntu.com/security/CVE-2026-63388", "cve_description": "Libevent is an event notification library. Prior to 2.1.13 and 2.2.2-alpha, libevent has a heap out-of-bounds write in bufferevent_sock.c when bufferevent_socket_set_conn_address_ copies a kernel-supplied AF_UNIX peer address into bufferevent_private.conn_address. Release builds compiled with NDEBUG disable the EVUTIL_ASSERT length guard, and the evhttp accept path can pass a 110-byte sockaddr from accept() into the 28-byte field. An unauthenticated local peer able to connect to an AF_UNIX listener can overwrite the adjacent dns_request pointer and heap data, causing memory corruption with confidentiality, integrity, and availability impact. This issue is fixed in versions 2.1.13 and 2.2.2-alpha.", "cve_priority": "medium", "cve_public_date": "2026-08-20 18:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-63387", "url": "https://ubuntu.com/security/CVE-2026-63387", "cve_description": "Libevent is an event notification library. Prior to 2.1.13 and 2.2.2-alpha, libevent has an off-by-one stack buffer overflow in evdns.c when dnsname_to_labels formats a name-bearing DNS record at the end of the 64 KB stack buffer allocated by evdns_server_request_format_response. The final-label check permits j plus label_len plus one to equal buf_len, after which the terminating null byte is written to buf[buf_len]. A crafted DNS server response containing PTR, CNAME, MX, NS, or SOA data can trigger the one-byte out-of-bounds write and crash or corrupt the process. This issue is fixed in versions 2.1.13 and 2.2.2-alpha.", "cve_priority": "medium", "cve_public_date": "2026-08-20 18:16:00 UTC" }, { "cve": "CVE-2026-63388", "url": "https://ubuntu.com/security/CVE-2026-63388", "cve_description": "Libevent is an event notification library. Prior to 2.1.13 and 2.2.2-alpha, libevent has a heap out-of-bounds write in bufferevent_sock.c when bufferevent_socket_set_conn_address_ copies a kernel-supplied AF_UNIX peer address into bufferevent_private.conn_address. Release builds compiled with NDEBUG disable the EVUTIL_ASSERT length guard, and the evhttp accept path can pass a 110-byte sockaddr from accept() into the 28-byte field. An unauthenticated local peer able to connect to an AF_UNIX listener can overwrite the adjacent dns_request pointer and heap data, causing memory corruption with confidentiality, integrity, and availability impact. This issue is fixed in versions 2.1.13 and 2.2.2-alpha.", "cve_priority": "medium", "cve_public_date": "2026-08-20 18:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Out-of-bounds write in dnsname_to_labels.", " - debian/patches/CVE-2026-63387.patch: Correct off-by-one error in", " evdns.c", " - CVE-2026-63387", " * SECURITY UPDATE: Heap out-of-bounds write via AF_UNIX+http+NDEBUG.", " - debian/patches/CVE-2026-63388.patch: Allocate enough memory for AF_UNIX", " addresses and check length in bufferevent-internal.h,", " bufferevent_sock.c, and http.c", " - CVE-2026-63388", "" ], "package": "libevent", "version": "2.1.12-stable-9ubuntu2.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Kyle Kernick ", "date": "Wed, 23 Sep 2026 13:17:39 -0600" } ], "notes": null, "is_version_downgrade": false }, { "name": "libfreetype6:s390x", "from_version": { "source_package_name": "freetype", "source_package_version": "2.13.2+dfsg-1ubuntu0.1", "version": "2.13.2+dfsg-1ubuntu0.1" }, "to_version": { "source_package_name": "freetype", "source_package_version": "2.13.2+dfsg-1ubuntu0.2", "version": "2.13.2+dfsg-1ubuntu0.2" }, "cves": [ { "cve": "CVE-2026-95512", "url": "https://ubuntu.com/security/CVE-2026-95512", "cve_description": "A flaw was found in FreeType, specifically within its CID font loader. A remote attacker could exploit this vulnerability by tricking a user into opening content that embeds or references a specially crafted CID-keyed font. This crafted font can cause repeated allocations and decryptions of subroutine data across multiple font dictionaries, leading to excessive memory and CPU consumption. This can result in a denial of service (DoS) for the application or service processing the font, potentially causing it to hang or terminate.", "cve_priority": "medium", "cve_public_date": "2026-10-02 09:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-95512", "url": "https://ubuntu.com/security/CVE-2026-95512", "cve_description": "A flaw was found in FreeType, specifically within its CID font loader. A remote attacker could exploit this vulnerability by tricking a user into opening content that embeds or references a specially crafted CID-keyed font. This crafted font can cause repeated allocations and decryptions of subroutine data across multiple font dictionaries, leading to excessive memory and CPU consumption. This can result in a denial of service (DoS) for the application or service processing the font, potentially causing it to hang or terminate.", "cve_priority": "medium", "cve_public_date": "2026-10-02 09:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: DoS in CID font loader", " - debian/patches/CVE-2026-95512.patch: * src/cid/cidload.c (cid_read_subrs):", " Limit overlaps. in src/cid/cidload.c.", " - CVE-2026-95512", "" ], "package": "freetype", "version": "2.13.2+dfsg-1ubuntu0.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Mon, 05 Oct 2026 10:43:12 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libheif-plugin-aomdec:s390x", "from_version": { "source_package_name": "libheif", "source_package_version": "1.17.6-1ubuntu4.8", "version": "1.17.6-1ubuntu4.8" }, "to_version": { "source_package_name": "libheif", "source_package_version": "1.17.6-1ubuntu4.9", "version": "1.17.6-1ubuntu4.9" }, "cves": [ { "cve": "CVE-2026-84384", "url": "https://ubuntu.com/security/CVE-2026-84384", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. From 1.19.0 until 1.23.2, crafted HEIF or AVIF mime metadata and unci image data can cause decompress_brotli() and do_inflate() to grow accumulated output without an effective size limit or MemoryHandle accounting. The brotli path has no output bound, while the zlib path checks only a small temporary buffer in a branch that valid streams do not reach, and overlapping icef units can decompress the same payload repeatedly. HeifContext::interpret_heif_file_images() processes multiple compressed metadata items during file opening, allowing a small file to consume unbounded memory and terminate the process. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84448", "url": "https://ubuntu.com/security/CVE-2026-84448", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.23.2, the public heif_region_item_add_region_inline_mask_data() function in libheif/api/libheif/heif_regions.cc accepts mask_data_len without verifying that it equals the byte count required by width and height. A later heif_region_get_mask_image() call derives the read length from the region geometry, so an undersized stored buffer causes heif_region_get_inline_mask_image() to read beyond the heap allocation and copy adjacent bytes into the returned monochrome mask image. This can disclose heap data or crash an application that constructs region metadata through the writer API, while the file-parsing path is not affected because it validates the canonical mask size. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84449", "url": "https://ubuntu.com/security/CVE-2026-84449", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.19.6, Op_RGB24_32_to_YCbCr::convert_colorspace() stores image-plane strides in an integer width that can overflow for extremely large RGB images created through heif_image_create() and heif_image_add_plane(). The resulting wrapped stride causes the conversion loop in libheif/color-conversion/rgb2yuv.cc to compute an invalid input pointer and read beyond the allocated interleaved plane while heif_context_encode_image() performs RGB-to-YCbCr conversion. This can crash the encoding process. This issue is fixed in version 1.19.6.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-84384", "url": "https://ubuntu.com/security/CVE-2026-84384", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. From 1.19.0 until 1.23.2, crafted HEIF or AVIF mime metadata and unci image data can cause decompress_brotli() and do_inflate() to grow accumulated output without an effective size limit or MemoryHandle accounting. The brotli path has no output bound, while the zlib path checks only a small temporary buffer in a branch that valid streams do not reach, and overlapping icef units can decompress the same payload repeatedly. HeifContext::interpret_heif_file_images() processes multiple compressed metadata items during file opening, allowing a small file to consume unbounded memory and terminate the process. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84448", "url": "https://ubuntu.com/security/CVE-2026-84448", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.23.2, the public heif_region_item_add_region_inline_mask_data() function in libheif/api/libheif/heif_regions.cc accepts mask_data_len without verifying that it equals the byte count required by width and height. A later heif_region_get_mask_image() call derives the read length from the region geometry, so an undersized stored buffer causes heif_region_get_inline_mask_image() to read beyond the heap allocation and copy adjacent bytes into the returned monochrome mask image. This can disclose heap data or crash an application that constructs region metadata through the writer API, while the file-parsing path is not affected because it validates the canonical mask size. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84449", "url": "https://ubuntu.com/security/CVE-2026-84449", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.19.6, Op_RGB24_32_to_YCbCr::convert_colorspace() stores image-plane strides in an integer width that can overflow for extremely large RGB images created through heif_image_create() and heif_image_add_plane(). The resulting wrapped stride causes the conversion loop in libheif/color-conversion/rgb2yuv.cc to compute an invalid input pointer and read beyond the allocated interleaved plane while heif_context_encode_image() performs RGB-to-YCbCr conversion. This can crash the encoding process. This issue is fixed in version 1.19.6.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of service in HEIF or AVIF metadata parsing", " - debian/patches/CVE-2026-84384.patch: bound brotli/zlib decompression", " output in libheif/metadata_compression.cc", " - CVE-2026-84384", " * SECURITY UPDATE: Denial of service in", " heif_region_item_add_region_inline_mask_data", " - debian/patches/CVE-2026-84448-pre1.patch: advance the parse offset after", " inline mask data in libheif/region.cc", " - debian/patches/CVE-2026-84448.patch: Validate inline mask data length", " in region writer API in libheif/heif_regions.cc and", " ../heif_regions.h", " - CVE-2026-84448", " * SECURITY UPDATE: Integer overflow in image plane stride handling", " - debian/patches/CVE-2026-84449.patch: changed internal stride types", " from int to size_t and added an overflow guard at the public C API", " boundary in libheif/heif.cc, ../heif.h, ../uncompressed_image.cc,", " ../color-conversion/chroma_sampling.cc, ../hdr_sdr.cc,", " ../monochrome.cc, ../rgb2rgb.cc, ../rgb2yuv.cc,", " ../rgb2yuv_sharp.cc, ../yuv2rgb.cc, libheif/context.cc,", " ../pixelimage.cc, ../pixelimage.h, and libheif/mask_image.cc.", " - CVE-2026-84449", "" ], "package": "libheif", "version": "1.17.6-1ubuntu4.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Kyle Kernick ", "date": "Mon, 28 Sep 2026 11:26:33 -0600" } ], "notes": null, "is_version_downgrade": false }, { "name": "libheif-plugin-aomenc:s390x", "from_version": { "source_package_name": "libheif", "source_package_version": "1.17.6-1ubuntu4.8", "version": "1.17.6-1ubuntu4.8" }, "to_version": { "source_package_name": "libheif", "source_package_version": "1.17.6-1ubuntu4.9", "version": "1.17.6-1ubuntu4.9" }, "cves": [ { "cve": "CVE-2026-84384", "url": "https://ubuntu.com/security/CVE-2026-84384", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. From 1.19.0 until 1.23.2, crafted HEIF or AVIF mime metadata and unci image data can cause decompress_brotli() and do_inflate() to grow accumulated output without an effective size limit or MemoryHandle accounting. The brotli path has no output bound, while the zlib path checks only a small temporary buffer in a branch that valid streams do not reach, and overlapping icef units can decompress the same payload repeatedly. HeifContext::interpret_heif_file_images() processes multiple compressed metadata items during file opening, allowing a small file to consume unbounded memory and terminate the process. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84448", "url": "https://ubuntu.com/security/CVE-2026-84448", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.23.2, the public heif_region_item_add_region_inline_mask_data() function in libheif/api/libheif/heif_regions.cc accepts mask_data_len without verifying that it equals the byte count required by width and height. A later heif_region_get_mask_image() call derives the read length from the region geometry, so an undersized stored buffer causes heif_region_get_inline_mask_image() to read beyond the heap allocation and copy adjacent bytes into the returned monochrome mask image. This can disclose heap data or crash an application that constructs region metadata through the writer API, while the file-parsing path is not affected because it validates the canonical mask size. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84449", "url": "https://ubuntu.com/security/CVE-2026-84449", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.19.6, Op_RGB24_32_to_YCbCr::convert_colorspace() stores image-plane strides in an integer width that can overflow for extremely large RGB images created through heif_image_create() and heif_image_add_plane(). The resulting wrapped stride causes the conversion loop in libheif/color-conversion/rgb2yuv.cc to compute an invalid input pointer and read beyond the allocated interleaved plane while heif_context_encode_image() performs RGB-to-YCbCr conversion. This can crash the encoding process. This issue is fixed in version 1.19.6.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-84384", "url": "https://ubuntu.com/security/CVE-2026-84384", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. From 1.19.0 until 1.23.2, crafted HEIF or AVIF mime metadata and unci image data can cause decompress_brotli() and do_inflate() to grow accumulated output without an effective size limit or MemoryHandle accounting. The brotli path has no output bound, while the zlib path checks only a small temporary buffer in a branch that valid streams do not reach, and overlapping icef units can decompress the same payload repeatedly. HeifContext::interpret_heif_file_images() processes multiple compressed metadata items during file opening, allowing a small file to consume unbounded memory and terminate the process. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84448", "url": "https://ubuntu.com/security/CVE-2026-84448", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.23.2, the public heif_region_item_add_region_inline_mask_data() function in libheif/api/libheif/heif_regions.cc accepts mask_data_len without verifying that it equals the byte count required by width and height. A later heif_region_get_mask_image() call derives the read length from the region geometry, so an undersized stored buffer causes heif_region_get_inline_mask_image() to read beyond the heap allocation and copy adjacent bytes into the returned monochrome mask image. This can disclose heap data or crash an application that constructs region metadata through the writer API, while the file-parsing path is not affected because it validates the canonical mask size. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84449", "url": "https://ubuntu.com/security/CVE-2026-84449", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.19.6, Op_RGB24_32_to_YCbCr::convert_colorspace() stores image-plane strides in an integer width that can overflow for extremely large RGB images created through heif_image_create() and heif_image_add_plane(). The resulting wrapped stride causes the conversion loop in libheif/color-conversion/rgb2yuv.cc to compute an invalid input pointer and read beyond the allocated interleaved plane while heif_context_encode_image() performs RGB-to-YCbCr conversion. This can crash the encoding process. This issue is fixed in version 1.19.6.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of service in HEIF or AVIF metadata parsing", " - debian/patches/CVE-2026-84384.patch: bound brotli/zlib decompression", " output in libheif/metadata_compression.cc", " - CVE-2026-84384", " * SECURITY UPDATE: Denial of service in", " heif_region_item_add_region_inline_mask_data", " - debian/patches/CVE-2026-84448-pre1.patch: advance the parse offset after", " inline mask data in libheif/region.cc", " - debian/patches/CVE-2026-84448.patch: Validate inline mask data length", " in region writer API in libheif/heif_regions.cc and", " ../heif_regions.h", " - CVE-2026-84448", " * SECURITY UPDATE: Integer overflow in image plane stride handling", " - debian/patches/CVE-2026-84449.patch: changed internal stride types", " from int to size_t and added an overflow guard at the public C API", " boundary in libheif/heif.cc, ../heif.h, ../uncompressed_image.cc,", " ../color-conversion/chroma_sampling.cc, ../hdr_sdr.cc,", " ../monochrome.cc, ../rgb2rgb.cc, ../rgb2yuv.cc,", " ../rgb2yuv_sharp.cc, ../yuv2rgb.cc, libheif/context.cc,", " ../pixelimage.cc, ../pixelimage.h, and libheif/mask_image.cc.", " - CVE-2026-84449", "" ], "package": "libheif", "version": "1.17.6-1ubuntu4.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Kyle Kernick ", "date": "Mon, 28 Sep 2026 11:26:33 -0600" } ], "notes": null, "is_version_downgrade": false }, { "name": "libheif1:s390x", "from_version": { "source_package_name": "libheif", "source_package_version": "1.17.6-1ubuntu4.8", "version": "1.17.6-1ubuntu4.8" }, "to_version": { "source_package_name": "libheif", "source_package_version": "1.17.6-1ubuntu4.9", "version": "1.17.6-1ubuntu4.9" }, "cves": [ { "cve": "CVE-2026-84384", "url": "https://ubuntu.com/security/CVE-2026-84384", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. From 1.19.0 until 1.23.2, crafted HEIF or AVIF mime metadata and unci image data can cause decompress_brotli() and do_inflate() to grow accumulated output without an effective size limit or MemoryHandle accounting. The brotli path has no output bound, while the zlib path checks only a small temporary buffer in a branch that valid streams do not reach, and overlapping icef units can decompress the same payload repeatedly. HeifContext::interpret_heif_file_images() processes multiple compressed metadata items during file opening, allowing a small file to consume unbounded memory and terminate the process. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84448", "url": "https://ubuntu.com/security/CVE-2026-84448", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.23.2, the public heif_region_item_add_region_inline_mask_data() function in libheif/api/libheif/heif_regions.cc accepts mask_data_len without verifying that it equals the byte count required by width and height. A later heif_region_get_mask_image() call derives the read length from the region geometry, so an undersized stored buffer causes heif_region_get_inline_mask_image() to read beyond the heap allocation and copy adjacent bytes into the returned monochrome mask image. This can disclose heap data or crash an application that constructs region metadata through the writer API, while the file-parsing path is not affected because it validates the canonical mask size. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84449", "url": "https://ubuntu.com/security/CVE-2026-84449", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.19.6, Op_RGB24_32_to_YCbCr::convert_colorspace() stores image-plane strides in an integer width that can overflow for extremely large RGB images created through heif_image_create() and heif_image_add_plane(). The resulting wrapped stride causes the conversion loop in libheif/color-conversion/rgb2yuv.cc to compute an invalid input pointer and read beyond the allocated interleaved plane while heif_context_encode_image() performs RGB-to-YCbCr conversion. This can crash the encoding process. This issue is fixed in version 1.19.6.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-84384", "url": "https://ubuntu.com/security/CVE-2026-84384", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. From 1.19.0 until 1.23.2, crafted HEIF or AVIF mime metadata and unci image data can cause decompress_brotli() and do_inflate() to grow accumulated output without an effective size limit or MemoryHandle accounting. The brotli path has no output bound, while the zlib path checks only a small temporary buffer in a branch that valid streams do not reach, and overlapping icef units can decompress the same payload repeatedly. HeifContext::interpret_heif_file_images() processes multiple compressed metadata items during file opening, allowing a small file to consume unbounded memory and terminate the process. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84448", "url": "https://ubuntu.com/security/CVE-2026-84448", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.23.2, the public heif_region_item_add_region_inline_mask_data() function in libheif/api/libheif/heif_regions.cc accepts mask_data_len without verifying that it equals the byte count required by width and height. A later heif_region_get_mask_image() call derives the read length from the region geometry, so an undersized stored buffer causes heif_region_get_inline_mask_image() to read beyond the heap allocation and copy adjacent bytes into the returned monochrome mask image. This can disclose heap data or crash an application that constructs region metadata through the writer API, while the file-parsing path is not affected because it validates the canonical mask size. This issue is fixed in version 1.23.2.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" }, { "cve": "CVE-2026-84449", "url": "https://ubuntu.com/security/CVE-2026-84449", "cve_description": "libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.19.6, Op_RGB24_32_to_YCbCr::convert_colorspace() stores image-plane strides in an integer width that can overflow for extremely large RGB images created through heif_image_create() and heif_image_add_plane(). The resulting wrapped stride causes the conversion loop in libheif/color-conversion/rgb2yuv.cc to compute an invalid input pointer and read beyond the allocated interleaved plane while heif_context_encode_image() performs RGB-to-YCbCr conversion. This can crash the encoding process. This issue is fixed in version 1.19.6.", "cve_priority": "medium", "cve_public_date": "2026-09-18 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of service in HEIF or AVIF metadata parsing", " - debian/patches/CVE-2026-84384.patch: bound brotli/zlib decompression", " output in libheif/metadata_compression.cc", " - CVE-2026-84384", " * SECURITY UPDATE: Denial of service in", " heif_region_item_add_region_inline_mask_data", " - debian/patches/CVE-2026-84448-pre1.patch: advance the parse offset after", " inline mask data in libheif/region.cc", " - debian/patches/CVE-2026-84448.patch: Validate inline mask data length", " in region writer API in libheif/heif_regions.cc and", " ../heif_regions.h", " - CVE-2026-84448", " * SECURITY UPDATE: Integer overflow in image plane stride handling", " - debian/patches/CVE-2026-84449.patch: changed internal stride types", " from int to size_t and added an overflow guard at the public C API", " boundary in libheif/heif.cc, ../heif.h, ../uncompressed_image.cc,", " ../color-conversion/chroma_sampling.cc, ../hdr_sdr.cc,", " ../monochrome.cc, ../rgb2rgb.cc, ../rgb2yuv.cc,", " ../rgb2yuv_sharp.cc, ../yuv2rgb.cc, libheif/context.cc,", " ../pixelimage.cc, ../pixelimage.h, and libheif/mask_image.cc.", " - CVE-2026-84449", "" ], "package": "libheif", "version": "1.17.6-1ubuntu4.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Kyle Kernick ", "date": "Mon, 28 Sep 2026 11:26:33 -0600" } ], "notes": null, "is_version_downgrade": false }, { "name": "libnss-systemd:s390x", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "libopeniscsiusr", "from_version": { "source_package_name": "open-iscsi", "source_package_version": "2.1.9-3ubuntu5.4", "version": "2.1.9-3ubuntu5.4" }, "to_version": { "source_package_name": "open-iscsi", "source_package_version": "2.1.9-3ubuntu5.5", "version": "2.1.9-3ubuntu5.5" }, "cves": [], "launchpad_bugs_fixed": [ 2147499 ], "changes": [ { "cves": [], "log": [ "", " * d/extra/initramfs/local-top/iscsi: normalize static bootproto for", " initramfs netplan conversion. In iscsi_auto flow, firmware reports", " bootproto as STATIC, but netinfo_to_netplan handles static IPv4", " through PROTO=none with address fields. Map STATIC to PROTO=none", " and record IPV4PROTO=static in net-*.conf. (LP: #2147499)", "" ], "package": "open-iscsi", "version": "2.1.9-3ubuntu5.5", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2147499 ], "author": "Zhang Hua ", "date": "Fri, 03 Jul 2026 17:01:52 +0800" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpam-systemd:s390x", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpng16-16t64:s390x", "from_version": { "source_package_name": "libpng1.6", "source_package_version": "1.6.43-5ubuntu0.6", "version": "1.6.43-5ubuntu0.6" }, "to_version": { "source_package_name": "libpng1.6", "source_package_version": "1.6.43-5ubuntu0.7", "version": "1.6.43-5ubuntu0.7" }, "cves": [ { "cve": "CVE-2026-46675", "url": "https://ubuntu.com/security/CVE-2026-46675", "cve_description": "[Use-after-free of zlib input in `png_read_end` after incomplete zTXt, iTXt or iCCP decompression]", "cve_priority": "medium", "cve_public_date": "2026-09-29" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-46675", "url": "https://ubuntu.com/security/CVE-2026-46675", "cve_description": "[Use-after-free of zlib input in `png_read_end` after incomplete zTXt, iTXt or iCCP decompression]", "cve_priority": "medium", "cve_public_date": "2026-09-29" } ], "log": [ "", " * SECURITY UPDATE: Use-after-free in png_read_end", " - debian/patches/CVE-2026-46675.patch: Clear stale zstream pointers when", " releasing the inflate stream in pngrutil.c", " - CVE-2026-46675", "" ], "package": "libpng1.6", "version": "1.6.43-5ubuntu0.7", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Kyle Kernick ", "date": "Mon, 05 Oct 2026 15:37:18 -0600" } ], "notes": null, "is_version_downgrade": false }, { "name": "libsgutils2-1.46-2:s390x", "from_version": { "source_package_name": "sg3-utils", "source_package_version": "1.46-3ubuntu4", "version": "1.46-3ubuntu4" }, "to_version": { "source_package_name": "sg3-utils", "source_package_version": "1.46-3ubuntu4.1", "version": "1.46-3ubuntu4.1" }, "cves": [ { "cve": "CVE-2026-16313", "url": "https://ubuntu.com/security/CVE-2026-16313", "cve_description": "A flaw was found in sg3_utils. The sg_inq command, when invoked with the --export option, outputs device identification data without sanitizing control characters in SCSI name string fields. A newline character embedded in a device-supplied name string can inject arbitrary properties into the udev device database. This could allow an attacker who can present a crafted SCSI device to execute arbitrary commands as root when the device is disconnected.", "cve_priority": "medium", "cve_public_date": "2026-07-28 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-16313", "url": "https://ubuntu.com/security/CVE-2026-16313", "cve_description": "A flaw was found in sg3_utils. The sg_inq command, when invoked with the --export option, outputs device identification data without sanitizing control characters in SCSI name string fields. A newline character embedded in a device-supplied name string can inject arbitrary properties into the udev device database. This could allow an attacker who can present a crafted SCSI device to execute arbitrary commands as root when the device is disconnected.", "cve_priority": "medium", "cve_public_date": "2026-07-28 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: command injection via udev property injection", " - debian/patches/CVE-2026-16313.patch: apply udev-conforming character", " encoding to the VPD 0x83 SCSI name string and T10 vendor ID ATA", " subfield output of sg_inq --export, so a crafted SCSI device cannot", " inject udev properties and execute commands as root (fix released", " upstream in sg3_utils 1.49).", " - debian/patches/CVE-2026-16313_2.patch: avoid including 0-bytes in SCSI", " name strings (upstream follow-up fix).", " - CVE-2026-16313", "" ], "package": "sg3-utils", "version": "1.46-3ubuntu4.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Allen Huang ", "date": "Thu, 01 Oct 2026 14:12:14 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "libssl3t64:s390x", "from_version": { "source_package_name": "openssl", "source_package_version": "3.0.13-0ubuntu3.15", "version": "3.0.13-0ubuntu3.15" }, "to_version": { "source_package_name": "openssl", "source_package_version": "3.0.13-0ubuntu3.16", "version": "3.0.13-0ubuntu3.16" }, "cves": [ { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Excessive Memory Allocation in Relative CRLDP Processing", " - debian/patches/CVE-2026-35189.patch: Defer computation of relative CRLDP", " names in crypto/x509/v3_crld.c, crypto/x509/v3_purp.c,", " crypto/x509/x509_vfy.c, include/crypto/x509.h.", " - CVE-2026-35189", " * SECURITY UPDATE: Timing Side-Channel in Scalar Multiplication for Non-NIST", " EC Curves", " - debian/patches/CVE-2026-54872-pre1.patch: add value_barrier_bn() to", " include/internal/constant_time.h.", " - debian/patches/CVE-2026-54872.patch: ec: make ossl_ec_scalar_mul_ladder()", " scalar padding constant time in crypto/bn/bn_intern.c,", " crypto/ec/ec_mult.c, include/crypto/bn.h.", " - CVE-2026-54872", " * SECURITY UPDATE: NULL Pointer Dereference in CMP Client Revocation Response", " Handling", " - debian/patches/CVE-2026-75805-1.patch: Guard comparison when values are", " NULL in crypto/cmp/cmp_client.c.", " - debian/patches/CVE-2026-75805-2.patch: Add test for CVE-2026-75805 in", " test/cmp_client_test.c.", " - CVE-2026-75805", " * SECURITY UPDATE: Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes", " DoS", " - debian/patches/CVE-2026-75806.patch: TLS: Reject undersized TLS 1.2 AEAD", " records before AEAD processing in ssl/record/record.h,", " ssl/record/ssl3_record.c, ssl/t1_enc.c, test/recordlentest.c.", " - CVE-2026-75806", " * SECURITY UPDATE: Timing Side-Channel in SM2 Signature Generation", " - debian/patches/CVE-2026-77696.patch: sm2: make sm2_sig_gen() constant time", " in crypto/ec/ec_mult.c, crypto/sm2/sm2_sign.c.", " - CVE-2026-77696", " * SECURITY UPDATE: DTLS Retransmits Handshake Messages From a Stale Buffer", " Offset", " - debian/patches/CVE-2026-84782.patch: dtls: reset init_off before", " retransmitting a message in ssl/d1_lib.c, ssl/statem/statem_dtls.c,", " test/dtlstest.c.", " - CVE-2026-84782", "" ], "package": "openssl", "version": "3.0.13-0ubuntu3.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 16 Sep 2026 14:47:02 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libsystemd-shared:s390x", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "libsystemd0:s390x", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "libudev1:s390x", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "libx11-6:s390x", "from_version": { "source_package_name": "libx11", "source_package_version": "2:1.8.7-1build1", "version": "2:1.8.7-1build1" }, "to_version": { "source_package_name": "libx11", "source_package_version": "2:1.8.7-1ubuntu0.1", "version": "2:1.8.7-1ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-88806", "url": "https://ubuntu.com/security/CVE-2026-88806", "cve_description": "A malicious X server could exploit a buffer overflow in libX11 before 1.8.14 during handling of XkbGetMap overflowing the key_sym_map.", "cve_priority": "medium", "cve_public_date": "2026-09-21 14:17:00 UTC" }, { "cve": "CVE-2026-94283", "url": "https://ubuntu.com/security/CVE-2026-94283", "cve_description": "An out-of-bounds read vulnerability in libX11's XIM (X Input Method) attribute parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" }, { "cve": "CVE-2026-94284", "url": "https://ubuntu.com/security/CVE-2026-94284", "cve_description": "An out-of-bounds read vulnerability in libX11's XIM trigger-key registration parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" }, { "cve": "CVE-2026-94285", "url": "https://ubuntu.com/security/CVE-2026-94285", "cve_description": "An out-of-bounds read in libX11's byte-oriented codeset parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-88806", "url": "https://ubuntu.com/security/CVE-2026-88806", "cve_description": "A malicious X server could exploit a buffer overflow in libX11 before 1.8.14 during handling of XkbGetMap overflowing the key_sym_map.", "cve_priority": "medium", "cve_public_date": "2026-09-21 14:17:00 UTC" }, { "cve": "CVE-2026-94283", "url": "https://ubuntu.com/security/CVE-2026-94283", "cve_description": "An out-of-bounds read vulnerability in libX11's XIM (X Input Method) attribute parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" }, { "cve": "CVE-2026-94284", "url": "https://ubuntu.com/security/CVE-2026-94284", "cve_description": "An out-of-bounds read vulnerability in libX11's XIM trigger-key registration parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" }, { "cve": "CVE-2026-94285", "url": "https://ubuntu.com/security/CVE-2026-94285", "cve_description": "An out-of-bounds read in libX11's byte-oriented codeset parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: heap buffer overflow in _XkbReadKeyActions()", " - debian/patches/CVE-2026-88806.patch: check the keysym range in", " _XkbReadKeyActions() in src/xkb/XKBGetMap.c.", " - CVE-2026-88806", " * SECURITY UPDATE: out-of-bounds read in XIM attribute parser", " - debian/patches/CVE-2026-94283.patch: bound XIM_OPEN_REPLY attribute", " lengths to the received packet in modules/im/ximcp/imDefIm.c,", " modules/im/ximcp/imRmAttr.c and src/xlibi18n/XimintP.h.", " - CVE-2026-94283", " * SECURITY UPDATE: out-of-bounds read in XIM trigger-key registration", " - debian/patches/CVE-2026-94284.patch: bound XIM_REGISTER_TRIGGERKEYS", " keylist lengths to the packet in modules/im/ximcp/imDefLkup.c.", " - CVE-2026-94284", " * SECURITY UPDATE: out-of-bounds read in byte-oriented codeset parser", " - debian/patches/CVE-2026-94285.patch: bound byteM_parse_codeset() reads", " to the remaining input length in modules/lc/gen/lcGenConv.c.", " - CVE-2026-94285", "" ], "package": "libx11", "version": "2:1.8.7-1ubuntu0.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Nick Galanis ", "date": "Thu, 08 Oct 2026 14:13:19 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "libx11-data", "from_version": { "source_package_name": "libx11", "source_package_version": "2:1.8.7-1build1", "version": "2:1.8.7-1build1" }, "to_version": { "source_package_name": "libx11", "source_package_version": "2:1.8.7-1ubuntu0.1", "version": "2:1.8.7-1ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-88806", "url": "https://ubuntu.com/security/CVE-2026-88806", "cve_description": "A malicious X server could exploit a buffer overflow in libX11 before 1.8.14 during handling of XkbGetMap overflowing the key_sym_map.", "cve_priority": "medium", "cve_public_date": "2026-09-21 14:17:00 UTC" }, { "cve": "CVE-2026-94283", "url": "https://ubuntu.com/security/CVE-2026-94283", "cve_description": "An out-of-bounds read vulnerability in libX11's XIM (X Input Method) attribute parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" }, { "cve": "CVE-2026-94284", "url": "https://ubuntu.com/security/CVE-2026-94284", "cve_description": "An out-of-bounds read vulnerability in libX11's XIM trigger-key registration parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" }, { "cve": "CVE-2026-94285", "url": "https://ubuntu.com/security/CVE-2026-94285", "cve_description": "An out-of-bounds read in libX11's byte-oriented codeset parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-88806", "url": "https://ubuntu.com/security/CVE-2026-88806", "cve_description": "A malicious X server could exploit a buffer overflow in libX11 before 1.8.14 during handling of XkbGetMap overflowing the key_sym_map.", "cve_priority": "medium", "cve_public_date": "2026-09-21 14:17:00 UTC" }, { "cve": "CVE-2026-94283", "url": "https://ubuntu.com/security/CVE-2026-94283", "cve_description": "An out-of-bounds read vulnerability in libX11's XIM (X Input Method) attribute parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" }, { "cve": "CVE-2026-94284", "url": "https://ubuntu.com/security/CVE-2026-94284", "cve_description": "An out-of-bounds read vulnerability in libX11's XIM trigger-key registration parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" }, { "cve": "CVE-2026-94285", "url": "https://ubuntu.com/security/CVE-2026-94285", "cve_description": "An out-of-bounds read in libX11's byte-oriented codeset parser in libX11 before 1.8.14 could be used by malicious X servers to crash attached X clients.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: heap buffer overflow in _XkbReadKeyActions()", " - debian/patches/CVE-2026-88806.patch: check the keysym range in", " _XkbReadKeyActions() in src/xkb/XKBGetMap.c.", " - CVE-2026-88806", " * SECURITY UPDATE: out-of-bounds read in XIM attribute parser", " - debian/patches/CVE-2026-94283.patch: bound XIM_OPEN_REPLY attribute", " lengths to the received packet in modules/im/ximcp/imDefIm.c,", " modules/im/ximcp/imRmAttr.c and src/xlibi18n/XimintP.h.", " - CVE-2026-94283", " * SECURITY UPDATE: out-of-bounds read in XIM trigger-key registration", " - debian/patches/CVE-2026-94284.patch: bound XIM_REGISTER_TRIGGERKEYS", " keylist lengths to the packet in modules/im/ximcp/imDefLkup.c.", " - CVE-2026-94284", " * SECURITY UPDATE: out-of-bounds read in byte-oriented codeset parser", " - debian/patches/CVE-2026-94285.patch: bound byteM_parse_codeset() reads", " to the remaining input length in modules/lc/gen/lcGenConv.c.", " - CVE-2026-94285", "" ], "package": "libx11", "version": "2:1.8.7-1ubuntu0.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Nick Galanis ", "date": "Thu, 08 Oct 2026 14:13:19 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "libxml2:s390x", "from_version": { "source_package_name": "libxml2", "source_package_version": "2.9.14+dfsg-1.3ubuntu3.9", "version": "2.9.14+dfsg-1.3ubuntu3.9" }, "to_version": { "source_package_name": "libxml2", "source_package_version": "2.9.14+dfsg-1.3ubuntu3.10", "version": "2.9.14+dfsg-1.3ubuntu3.10" }, "cves": [ { "cve": "CVE-2026-76781", "url": "https://ubuntu.com/security/CVE-2026-76781", "cve_description": "A flaw was found in libxml2. A local user or an attacker providing a specially crafted XML catalog can trigger a NULL pointer dereference during XML catalog parsing. This occurs when a `nextCatalog` element lacks its mandatory `catalog` attribute, leading to the application crashing and causing a Denial of Service (DoS).", "cve_priority": "medium", "cve_public_date": "2026-09-17 16:17:00 UTC" }, { "cve": "CVE-2026-86138", "url": "https://ubuntu.com/security/CVE-2026-86138", "cve_description": "In libxml2 before 2.15.4, xmlDictAddQString in dict.c has an integer overflow and resultant heap-based buffer overflow.", "cve_priority": "medium", "cve_public_date": "2026-09-05 05:17:00 UTC" }, { "cve": "CVE-2026-86142", "url": "https://ubuntu.com/security/CVE-2026-86142", "cve_description": "In libxml2 before 2.15.4, there is a heap-based buffer overflow in xmlXPtrEvalXPtrPart because of xmlXPtrEval xpointer length saturation.", "cve_priority": "medium", "cve_public_date": "2026-09-05 05:17:00 UTC" }, { "cve": "CVE-2026-86143", "url": "https://ubuntu.com/security/CVE-2026-86143", "cve_description": "In xmlIO in libxml2 before 2.15.4, an inconsistency in xmlOutputWriteCallback and xmlBufUse causes negative lengths to reach write callbacks, aka a lack of a check for integer overflow before calling writecallback. This has security relevance for many types of uses of that length value within a callback.", "cve_priority": "medium", "cve_public_date": "2026-09-05 05:17:00 UTC" }, { "cve": "CVE-2026-86144", "url": "https://ubuntu.com/security/CVE-2026-86144", "cve_description": "In xinclude in libxml2 before 2.15.4, xmlXIncludeProcess and xmlXIncludeProcessTree do not propagate parseFlags. This has security relevance for, for example, the XML_PARSE_NONET flag, if (without it) a custom resource loader accesses the internet and triggers XML external entity injection, SSRF, or a denial of service (e.g., for an attacker-controlled internet resource that is intentionally slow).", "cve_priority": "medium", "cve_public_date": "2026-09-05 05:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-76781", "url": "https://ubuntu.com/security/CVE-2026-76781", "cve_description": "A flaw was found in libxml2. A local user or an attacker providing a specially crafted XML catalog can trigger a NULL pointer dereference during XML catalog parsing. This occurs when a `nextCatalog` element lacks its mandatory `catalog` attribute, leading to the application crashing and causing a Denial of Service (DoS).", "cve_priority": "medium", "cve_public_date": "2026-09-17 16:17:00 UTC" }, { "cve": "CVE-2026-86138", "url": "https://ubuntu.com/security/CVE-2026-86138", "cve_description": "In libxml2 before 2.15.4, xmlDictAddQString in dict.c has an integer overflow and resultant heap-based buffer overflow.", "cve_priority": "medium", "cve_public_date": "2026-09-05 05:17:00 UTC" }, { "cve": "CVE-2026-86142", "url": "https://ubuntu.com/security/CVE-2026-86142", "cve_description": "In libxml2 before 2.15.4, there is a heap-based buffer overflow in xmlXPtrEvalXPtrPart because of xmlXPtrEval xpointer length saturation.", "cve_priority": "medium", "cve_public_date": "2026-09-05 05:17:00 UTC" }, { "cve": "CVE-2026-86143", "url": "https://ubuntu.com/security/CVE-2026-86143", "cve_description": "In xmlIO in libxml2 before 2.15.4, an inconsistency in xmlOutputWriteCallback and xmlBufUse causes negative lengths to reach write callbacks, aka a lack of a check for integer overflow before calling writecallback. This has security relevance for many types of uses of that length value within a callback.", "cve_priority": "medium", "cve_public_date": "2026-09-05 05:17:00 UTC" }, { "cve": "CVE-2026-86144", "url": "https://ubuntu.com/security/CVE-2026-86144", "cve_description": "In xinclude in libxml2 before 2.15.4, xmlXIncludeProcess and xmlXIncludeProcessTree do not propagate parseFlags. This has security relevance for, for example, the XML_PARSE_NONET flag, if (without it) a custom resource loader accesses the internet and triggers XML external entity injection, SSRF, or a denial of service (e.g., for an attacker-controlled internet resource that is intentionally slow).", "cve_priority": "medium", "cve_public_date": "2026-09-05 05:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: NULL pointer dereference when parsing XML catalogs", " - debian/patches/CVE-2026-76781.patch: Skip the duplicate nextCatalog", " check when the catalog attribute is missing in catalog.c.", " - CVE-2026-76781", " * SECURITY UPDATE: integer overflow leading to heap-based buffer overflow", " in xmlDictAddQString", " - debian/patches/CVE-2026-86138.patch: Add overflow checks to the pool", " size calculations in xmlDictAddQString in dict.c.", " - CVE-2026-86138", " * SECURITY UPDATE: heap-based buffer overflow in XPointer evaluation", " - debian/patches/CVE-2026-86142.patch: Return an error when xmlStrlen", " reports an overflowed expression in xmlXPtrEvalXPtrPart in xpointer.c.", " - CVE-2026-86142", " * SECURITY UPDATE: integer overflow in length passed to output callbacks", " - debian/patches/CVE-2026-86143.patch: Fail when the output buffer holds", " >= INT_MAX bytes in xmlIO.c.", " - CVE-2026-86143", " * SECURITY UPDATE: XInclude processing ignores parse flags", " - debian/patches/CVE-2026-86144.patch: Pass the document parseFlags to", " xmlXIncludeProcess and xmlXIncludeProcessTree and apply parse flags", " to text includes in xinclude.c.", " - CVE-2026-86144", "" ], "package": "libxml2", "version": "2.9.14+dfsg-1.3ubuntu3.10", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Charles Cochran ", "date": "Tue, 06 Oct 2026 12:40:57 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libxpm4:s390x", "from_version": { "source_package_name": "libxpm", "source_package_version": "1:3.5.17-1ubuntu0.24.04.1", "version": "1:3.5.17-1ubuntu0.24.04.1" }, "to_version": { "source_package_name": "libxpm", "source_package_version": "1:3.5.17-1ubuntu0.24.04.2", "version": "1:3.5.17-1ubuntu0.24.04.2" }, "cves": [ { "cve": "CVE-2026-94287", "url": "https://ubuntu.com/security/CVE-2026-94287", "cve_description": "A denial of service via unsigned underflow in libXpm's write path in libXpm before 3.5.19 could be used by local attackers to cause unbounded CPU usage and memory exhaustion.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-94287", "url": "https://ubuntu.com/security/CVE-2026-94287", "cve_description": "A denial of service via unsigned underflow in libXpm's write path in libXpm before 3.5.19 could be used by local attackers to cause unbounded CPU usage and memory exhaustion.", "cve_priority": "medium", "cve_public_date": "2026-09-28 09:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: infinite write loop", " - debian/patches/CVE-2026-94287.patch: ParsePixels: reject zero-dimension", " XPM images in src/parse.c.", " - CVE-2026-94287", "" ], "package": "libxpm", "version": "1:3.5.17-1ubuntu0.24.04.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 29 Sep 2026 11:57:06 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-generic", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-147.147", "" ], "package": "linux-meta", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 12:33:08 +0200" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-146.146", "" ], "package": "linux-meta", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:48:49 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-145.145", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.8.0-145.145", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Tue, 01 Sep 2026 22:49:50 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-141.141", "" ], "package": "linux-meta", "version": "6.8.0-141.141", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Sat, 29 Aug 2026 11:37:32 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-147.147", "" ], "package": "linux-meta", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 12:33:08 +0200" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-146.146", "" ], "package": "linux-meta", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:48:49 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-145.145", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.8.0-145.145", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Tue, 01 Sep 2026 22:49:50 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-141.141", "" ], "package": "linux-meta", "version": "6.8.0-141.141", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Sat, 29 Aug 2026 11:37:32 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-147.147", "" ], "package": "linux-meta", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 12:33:08 +0200" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-146.146", "" ], "package": "linux-meta", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:48:49 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-145.145", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.8.0-145.145", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Tue, 01 Sep 2026 22:49:50 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-141.141", "" ], "package": "linux-meta", "version": "6.8.0-141.141", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Sat, 29 Aug 2026 11:37:32 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-libc-dev:s390x", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-147.147 -proposed tracker (LP: #2168142)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026)", " - platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug", " - selftests/bpf: Add tests for ld_{abs,ind} failure path in subprogs", " - drm/virtio: fix deadlock in display_info_cb by removing hotplug from", " dequeue worker", " - mtd: mtdswap: remove debugfs stats file on teardown", " - seqlock: Cure some more scoped_seqlock() optimization fails", " - seqlock: Allow KASAN to fail optimizing", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/umem: Add support for creating pinned DMABUF umem with a given dma", " device", " - RDMA/umem: Introduce an option to revoke DMABUF umem", " - RDMA/umem: Add ib_umem_dmabuf_get_pinned_and_lock helper", " - RDMA/umem: Move umem dmabuf revoke logic into helper function", " - RDMA/umem: Add pinned revocable dmabuf import interface", " - RDMA/umem: Add helpers for umem dmabuf revoke lock", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - selftests/alsa: Fix memory leak in find_controls error path", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: cs42l43: Correct report for forced microphone jack", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - sched/vtime: Get rid of generic vtime_task_switch() implementation", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - can: j1939: fix lockless local-destination check", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - crypto: rsa-pkcs1pad: Don't WARN on an empty digest", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - wifi: ath11k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - wifi: ath12k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - ASoC: cs35l56: Don't use devres to unregister component", " - ASoC: cs35l56: Fix potential probe() deadlock", " - ASoC: cs35l56: Use complete_all() to signal init_completion", " - wifi: iwlwifi: mvm: validate SAR GEO response payload size", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - hwmon: (asus-ec-sensors) fix looping over banks while reading from EC", " - hwmon: (asus-ec-sensors) fix EC read intervals", " - hwmon: (asus-ec-sensors) add missed handle for ENOMEM", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - pds_core: yield the CPU while waiting for the adminq to drain", " - pds_core: order completion reads after the ownership check", " - pds_core: check for workqueue allocation failure", " - tls: device: push pending open record on splice EOF", " - selftest: af_unix: Add Kconfig file.", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - amt: make the head writable before rewriting the L2 header", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: dpaa: fix mode setting", " - iomap: correct the range of a partial dirty clear", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - net: stmmac: enable the MAC on link up for all supported speeds", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - ppp: use IFF_NO_QUEUE in virtual interfaces", " - ppp: convert to percpu netstats", " - ppp: enable TX scatter-gather", " - ppp: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: fix LAG recipe to profile association", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't", " at 0 (v2)", " - drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nxp: imx8-isi: Clean up already-initialized pipes on probe", " failure", " - media: nxp: imx8-isi: Fix missing v4l2_subdev_cleanup() in pipe init", " error path", " - media: nxp: imx8-isi: Fix scale factor calculation for hardware rounding", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vivid: add vivid_update_reduced_fps()", " - media: vpif_capture: fix OF node reference imbalance", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - LoongArch: Fix oops during single-step debugging", " - x86/boot/compressed: Disable jump tables", " - serial: sc16is7xx: implement gpio get_direction() callback", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - ice: use READ_ONCE() to access cached PHC time", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amd/display: Fix dcn32 DTB DTO update breaking live pixel rate", " sources", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - net: pcs: xpcs: fix SGMII state reading", " - bpf: drop bpf_lsm_getselfattr from hook list", " - udmabuf: Do not create malformed scatterlists", " - i2c: davinci: Unregister cpufreq notifier on probe failure", " - VFS/audit: introduce kern_path_parent() for audit", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - rxrpc: Pull out certain app callback funcs into an ops table", " - fbcon: Rename struct fbcon_ops to struct fbcon_par", " - fbcon: Use correct type for vc_resize() return value", " - rxrpc: Don't need barrier for ->tx_bottom and ->acks_hard_ack", " - rxrpc: Use irq-disabling spinlocks between app and I/O thread", " - rxrpc: Fix notification vs call-release vs recvmsg", " - rxrpc: Fix socket notification race", " - vduse: Use fixed 4KB bounce pages for non-4KB page size", " - vduse: remove unused vaddr parameter of vduse_domain_free_coherent", " - vduse: take out allocations from vduse_dev_alloc_coherent", " - octeontx2: Annotate mmio regions as __iomem", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - fbdev/efifb: Replace references to global screen_info by local pointer", " - ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable()", " - ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe()", " - ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb", " - ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - netfilter: nft_set_pipapo: use GFP_KERNEL for insertions", " - netfilter: nft_set_pipapo: move prove_locking helper around", " - netfilter: nft_set_pipapo: make pipapo_clone helper return NULL", " - netfilter: nft_set_pipapo: prepare walk function for on-demand clone", " - netfilter: nft_set_pipapo: merge deactivate helper into caller", " - netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone", " - netfilter: nft_set_pipapo: move cloning of match info to insert/removal", " path", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_tables: Remove unused nft_reduce_is_readonly()", " - netfilter: nf_tables: remove register tracking infrastructure", " - NFSD: pass nfsd_file to nfsd_iter_read()", " - sunrpc: allocate a separate bvec array for socket sends", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - dma: dw-edma: Fix build warning in dw_edma_pcie_probe()", " - dmaengine: dw-edma: Fix confusing cleanup.h syntax", " - platform/x86: dell-smbios: Move request functions for reuse", " - i2c: imx: separate atomic, dma and non-dma use case", " - nfs: remove dead code for the old swap over NFS implementation", " - ovl: use linked upper dentry in copy-up tmpfile", " - bootconfig: do not put quotes on cmdline items unless necessary", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - rxrpc: Disable IRQ, not BH, to take the lock for ->attend_link", " - netfilter: nft_quota: use atomic64_xchg for reset", " - soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE", " - wifi: cfg80211: pass net_device to .set_monitor_channel", " - wifi: cfg80211: define and use wiphy guard", " - wifi: cfg80211: derive S1G beacon TSF from S1G fields", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - smb: move some duplicate definitions to common/cifsglob.h", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - wifi: mt76: mt7925: extend mt7925_mcu_bss_he_tlv for per-link BSS", " - ovl: fix trusted xattr escape prefix matching", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - dpll: add clock quality level attribute and op", " - net/mlx5: DPLL, Add clock quality level op implementation", " - net/mlx5: Remove newline at the end of a netlink error message", " - net/mlx5: Refactor EEPROM query error handling to return status", " separately", " - octeontx2-pf: tc: fix egress ratelimiting", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm/displayid: move drm_displayid.h to drm_displayd_internal.h", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - ALSA: timer: drain a slave's callback before its master detaches it", " - ALSA: timer: don't re-enter an instance callback that is still running", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - sysctl: treewide: constify ctl_table_header::ctl_table_arg", " - ceph: fix refcount leak in ceph_readdir()", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - net: move skb_gro_receive_list from udp to core", " - net: add pskb_may_pull() to skb_gro_receive_list()", " - vsock/virtio: collapse receive queue under memory pressure", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - xfs: add an explicit owner field to xfs_da_args", " - xfs: factor out xfs_attr3_leaf_init", " - xfs: don't replace the wrong part of the cow fork", " - rxrpc: Fix CPU time starvation in I/O thread", " - ASoC: mediatek: mt8183-afe-pcm: Shorten memif_data table using macros", " - ASoC: mediatek: mt8183-afe-pcm: Support >32 bit DMA addresses", " - tcp: Decrement tcp_md5_needed static branch", " - nvmet: Introduce nvmet_req_transfer_len()", " - block: add helper add_disk_final()", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections", " - Bluetooth: hci_core: Fix not accounting for BIS/CIS/PA links separately", " - afs: Improve server refcount/active count tracing", " - afs: Make afs_lookup_cell() take a trace note", " - afs: Drop the net parameter from afs_unuse_cell()", " - rxrpc: Allow the app to store private data on peer structs", " - afs: Use the per-peer app data provided by rxrpc", " - afs: Fix afs_server ref accounting", " - afs: Simplify cell record handling", " - afs: Fix dynamic lookup to fail on cell lookup failure", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - lib/string_choices: Add str_plural() helper", " - USB: gadget: Use str_enable_disable-like helpers", " - usb: musb: omap2430: clean up probe error handling", " - net/mlx5e: Fix NULL pointer dereference in ioctl module EEPROM query", " - rxrpc: Fix locking issues with the peer record hash", " - wifi: nl80211: fix nl80211_start_radar_detection return value", " - afs: Set vllist to NULL if addr parsing fails", " - dpll: fix clock quality level reporting", " - afs: Fix delayed allocation of a cell's anonymous key", " - afs: handle CB.InitCallBackState3 requests without a server record", " - Bluetooth: hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK", " - Bluetooth: hci_conn: Fix not cleaning up Broadcaster/Broadcast Source", " - Bluetooth: hci_conn: Remove redundant memset after kzalloc", " - Bluetooth: hci_conn: Fix not cleaning up PA_LINK connections", " - Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()", " - afs: Fix uninit var in afs_alloc_anon_key()", " - Upstream stable to v6.6.148, v6.12.101", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72168", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72213", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72244", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53078", " - bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2025-40098", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_get_acpi_mute_state()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68372", " - usb: core: port: Deattach Type-C connector on component unbind", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72175", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45901", " - netfilter: nf_tables: revert commit_mutex usage in reset path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45897", " - netfilter: nft_counter: serialize reset with spinlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72015", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72017", " - net: macb: drop in-flight Tx SKBs on close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72030", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72023", " - octeontx2-pf: fix SQB pointer leak on init failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72040", " - ipmi: fix refcount leak in i_ipmi_request()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72045", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72062", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72051", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72070", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72142", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72147", " - dmaengine: dw-edma-pcie: Reject devices without driver data", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72254", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72253", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72260", " - ASoC: mediatek: mt8192: Check runtime resume during probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72305", " - VDUSE: avoid leaking information to userspace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64205", " - i2c: i801: fix hardware state machine corruption in error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64280", " - fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72146", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72124", " - can: isotp: serialize TX state transitions under so->rx_lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72125", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72115", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72117", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72116", " - can: bcm: fix stale rx/tx ops after device removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72113", " - can: bcm: add missing device refcount for CAN filter removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72114", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72119", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72118", " - can: bcm: fix CAN frame rx/tx statistics", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72121", " - can: bcm: add locking when updating filter and timer values", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53090", " - bpf: Fix ld_{abs,ind} failure path analysis in subprogs", "", " * test_vxlan_vnifiltering.sh from ubuntu_kselftests_net failed on linux-", " oem-6.8 (with ipv6 default rdst) (LP: #2071590)", " - selftests: net: use slowwait to make sure IPv6 setup finished", "", " * ubuntu_bpf failed to build in noble (error: redefinition of", " 'stack_load_preserves_const_precision') (LP: #2160493)", " - SAUCE: Revert \"selftests/bpf: validate fake register spill/fill", " precision backtracking logic\"", "", " * CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", "", " * Backport: \"mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios\"", " (LP: #2162917)", " - mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios", "", " * qrtr: ns: node limit of 64 breaks QRTR routing on large multi-node", " deployments (LP: #2165140)", " - net: qrtr: ns: Raise node count limit to 512", "", " * [UBUNTU 24.04] kernel: CPU hotplug unsupported by CPUMF (LP: #2165732)", " - s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks", "", " * CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", "", " * CVE-2025-38563", " - perf/core: Prevent VMA split of buffer mappings", "", " * CVE-2025-38565", " - perf/core: Exit early on perf_mmap() fail", "", " * CVE-2025-38187", " - drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()", "", " * CVE-2025-38069", " - PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops", "", " * CVE-2025-40014", " - objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()", "", " * CVE-2025-21985", " - drm/amd/display: Fix out-of-bound accesses", "", " * CVE-2024-56552", " - drm/xe/guc_submit: fix race around suspend_pending", "", " * CVE-2025-21687", " - vfio/platform: check the bounds of read/write syscalls", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237)", " - ext4: fix fd leak in EXT4_IOC_MOVE_EXT cross-sb validation", " - mm: refactor mm_access() to not return NULL", " - Upstream stable to v6.6.146, v6.12.98, v6.6.147, v6.12.99, v6.12.100", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237) //", " CVE-2026-64560", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995)", " - bpf, arm64: Reject out-of-range B.cond targets", " - nfsd: release layout stid on setlease failure", " - Bluetooth: btmtk: apply the common btmtk_fw_get_filename", " - Bluetooth: btmtk: Fix failed to send func ctrl for MediaTek devices.", " - Bluetooth: btmtk: Fix wait_on_bit_timeout interruption during shutdown", " - userfaultfd: gate must_wait writability check on pte_present()", " - perf: Fix dangling cgroup pointer in cpuctx backport", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error", " - device property: initialize the remaining fields of fwnode_handle in", " fwnode_init()", " - f2fs: validate orphan inode entry count", " - f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode", " - f2fs: fix potential deadlock in f2fs_balance_fs()", " - f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()", " - f2fs: fix listxattr handling of corrupted xattr entries", " - block: Avoid mounting the bdev pseudo-filesystem in userspace", " - i2c: core: fix irq domain leak on adapter registration failure", " - i2c: core: fix hang on adapter registration failure", " - i2c: core: fix NULL-deref on adapter registration failure", " - i2c: core: fix adapter debugfs creation", " - fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()", " - NFSv4/flexfiles: reject zero filehandle version count", " - locking/rtmutex: Make sure we wake anything on the wake_q when we", " release the lock->wait_lock", " - bonding: fix xfrm offload feature setup on active-backup mode", " - mm/vmscan: flush deferred TLB before freeing large folios", " - perf trace beauty fcntl: Fix build with older kernel headers", " - ACPI: CPPC: Suppress UBSAN warning caused by field misuse", " - ACPI: NFIT: core: Fix possible NULL pointer dereference", " - perf/core: Detach event groups during remove_on_exec", " - arm64: sysreg: Add layout for ID_AA64MMFR4_EL1", " - virtio_net: Support dynamic rss indirection table size", " - LoongArch: Add PIO for early access before ACPI PCI root register", " - usb: gadget: function: rndis: add length check to response query", " - usb: gadget: function: rndis: add length check for header", " - iio: accel: bmc150: clamp the device-reported FIFO frame count", " - iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error", " - iio: adc: lpc32xx: Initialize completion before requesting IRQ", " - iio: adc: ti-ads124s08: Return reset GPIO lookup errors", " - iio: chemical: scd30: Cleanup initializations and fix sign-extension bug", " - iio: event: Fix event FIFO reset race", " - iio: gyro: bmg160: bail out when bandwidth/filter is not in table", " - iio: gyro: bmg160: wait full startup time after mode change at probe", " - iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ", " - iio: imu: st_lsm6dsx: deselect shub page before reading whoami", " - iio: light: al3010: fix incorrect scale for the highest gain range", " - iio: light: gp2ap002: fix runtime PM leak on read error", " - iio: light: opt3001: fix missing state reset on timeout", " - iio: light: tsl2591: return actual error from probe IRQ failure", " - iio: light: veml6030: fix channel type when pushing events", " - iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call", " - iio: temperature: ltc2983: Fix reinit_completion() called after", " conversion start", " - ALSA: virtio: Add missing 384 kHz PCM rate mapping", " - ALSA: ymfpci: check snd_ctl_new1() return value", " - ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input", " parser", " - ALSA: cmipci: check snd_ctl_new1() return value", " - ALSA: es1938: check snd_ctl_new1() return value", " - ALSA: firewire: isight: bound the sample count to the packet payload", " - ALSA: gus: check snd_ctl_new1() return value", " - ALSA: ice1712: check snd_ctl_new1() return value", " - ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()", " - ALSA: usb-audio: avoid kobject path lookup in DualSense match", " - ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()", " - ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch", " put callbacks", " - ALSA: usb-audio: Update Babyface Pro control caches only after", " successful writes", " - ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful", " writes", " - vfio/pci: Use a private flag to prevent power state change with VFs", " - vfio/pci: Latch disable_idle_d3 per device", " - vfio/pci: Release the VGA arbiter client on register_device() failure", " - vfio/pci: Fix racy bitfields and tighten struct layout", " - vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc", " - Bluetooth: btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB", " - Bluetooth: btusb: fix use-after-free on registration failure", " - Bluetooth: btusb: fix use-after-free on marvell probe failure", " - Bluetooth: btusb: fix wakeup source leak on probe failure", " - binder: fix UAF in binder_thread_release()", " - binder: fix UAF in binder_free_transaction()", " - usb: xhci: Fix sleep in atomic context in xhci_free_streams()", " - PCI: altera: Do not dispose parent IRQ mapping", " - mm/damon/ops-common: handle extreme intervals in damon_hot_score()", " - netfilter: ipset: fix race between dump and ip_set_list resize", " - virtio-mmio: fix device release warning on module unload", " - hwrng: virtio: clamp device-reported used.len at copy_data()", " - USB: chaoskey: Fix slab-use-after-free in chaoskey_release()", " - usb: dwc3: run gadget disconnect from sleepable suspend context", " - 6lowpan: fix NHC entry use-after-free on error path", " - tipc: fix out-of-bounds read in broadcast Gap ACK blocks", " - staging: vme_user: bound slave read/write to the kern_buf size", " - smb: client: restrict implied bcc[0] exemption to responses without data", " area", " - staging: vme_user: fix location monitor leak in fake bridge", " - staging: vme_user: fix location monitor leak in tsi148 bridge", " - media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe", " - staging: media: atomisp: reduce load_primary_binaries() stack usage", " - staging: rtl8723bs: fix heap buffer overflow in", " rtw_cfg80211_set_wpa_ie()", " - staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()", " - staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop", " - staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop", " - staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and", " join_cmd_hdl()", " - staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop", " - staging: rtl8723bs: fix OOB write in HT_caps_handler()", " - crypto: amlogic - avoid double cleanup in meson_crypto_probe()", " - ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then", " SMB2_CANCEL", " - net: af_key: initialize alg_key_len for IPComp states", " - audit: Fix data races of skb_queue_len() readers on audit_queue", " - Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete", " - debugobjects: Plug race against a concurrent OOM disable", " - fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns", " - NTB: epf: Avoid calling pci_irq_vector() from hardirq context", " - io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item", " - ipv4: igmp: remove multicast group from hash table on device destruction", " - net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes", " - mfd: cros_ec: Delay dev_set_drvdata() until probe success", " - mm: shrinker: fix NULL pointer dereference in debugfs", " - netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump", " - f2fs: bound i_inline_xattr_size for non-inline-xattr inodes", " - drm/amd: Fix set but not used warnings", " - apparmor: advertise the tcp fast open fix is applied", " - nfsd: move name lookup out of nfsd4_list_rec_dir()", " - nfsd: change nfs4_client_to_reclaim() to allocate data", " - arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative", " - arm64: Fix early handling of FEAT_E2H0 not being implemented", " - KVM: arm64: Initialize HCR_EL2.E2H early", " - arm64: Revamp HCR_EL2.E2H RES1 detection", " - arm64: sysreg: Correct sign definitions for EIESB and DoubleLock", " - iio: adc: spear: Initialize completion before requesting IRQ", " - iio: imu: inv_icm42600: fix timestamp clock period by using lower value", " - ALSA: usb-audio: Roll back quirk control caches on write errors", " - usb: typec: tcpci_rt1711h: unregister TCPCI port with devres", " - gpio: eic-sprd: use raw_spinlock_t in the irq startup path", " - netfilter: ebtables: module names must be null-terminated", " - netfilter: ebtables: terminate table name before find_table_lock()", " - Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()", " - Bluetooth: bnep: pin L2CAP connection during netdev registration", " - Bluetooth: btnxpuart: Fix out-of-bounds firmware read in", " nxp_recv_fw_req_v3()", " - Bluetooth: fix UAF in bt_accept_dequeue()", " - Bluetooth: L2CAP: validate option length before reading conf opt value", " - fs/ntfs3: fsync files by syncing parent inodes", " - fs/ntfs3: zero-fill folios beyond i_valid in ntfs_read_folio()", " - fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()", " - coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer()", " - smb/client: Fix error code in smb2_aead_req_alloc()", " - ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE", " - ksmbd: add a permission check for FSCTL_SET_ZERO_DATA", " - ksmbd: serialize QUERY_DIRECTORY requests per file", " - ksmbd: require source read access for duplicate extents", " - ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock", " cancellation", " - ksmbd: add a WRITE_DAC/WRITE_OWNER check to SMB2 SET_INFO SECURITY", " - ksmbd: run set info with opener credentials", " - ksmbd: enforce FILE_READ_ATTRIBUTES on SMB_FIND_FILE_POSIX_INFORMATION", " - ksmbd: add per-handle permission check to FILE_LINK_INFORMATION", " - ksmbd: use opener credentials for delete-on-close", " - smb: client: fix query directory replay double-free", " - smb: client: fix query_info() replay double-free", " - smb: client: fix double-free in SMB2_ioctl() replay", " - smb: client: fix change notify replay double-free", " - smb: client: fix double-free in SMB2_flush() replay", " - smb: client: fix double-free in SMB2_open() replay", " - smb: client: fix double-free in SMB2_close() replay", " - smb: client: Fix next buffer leak in receive_encrypted_standard()", " - smb: client: use unaligned reads in parse_posix_ctxt()", " - smb: client: harden POSIX SID length parsing", " - smb: client: mask server-provided mode to 07777 in modefromsid", " - OPP: of: Fix potential memory leak in opp_parse_supplies()", " - firmware_loader: fix device reference leak in firmware_upload_register()", " - cpufreq: intel_pstate: Sync policy->cur during CPU offline", " - sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT", " - cpufreq: Fix hotplug-suspend race during reboot", " - cpufreq: pcc: fix use-after-free and double free in _OSC evaluation", " - posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path", " - clocksource/drivers/timer-tegra186: Fix support for multiple watchdog", " instances", " - X.509: Fix validation of ASN.1 certificate header", " - tools/mm/slabinfo: Fix trace disable logic inversion", " - tools/mm/slabinfo: fix total_objects attribute name", " - HID: wacom: stop hardware after post-start probe failures", " - HID: letsketch: fix UAF on inrange_timer at driver unbind", " - HID: lg-g15: cancel pending work on remove to fix a use-after-free", " - HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte", " reads", " - hfs/hfsplus: zero-initialize buffer in hfs_bnode_read", " - nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers", " - media: mtk-jpeg: cancel workqueue on release for supported platforms", " only", " - xfs: use null daddr for unset first bad log block", " - xfs: fix unreachable BIGTIME check in dquot flush validation", " - bpf: Reject fragmented frames in devmap", " - bpf: Restore sysctl new-value from 1 to 0", " - net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()", " - usb: cdc_acm: Add quirk for Uniden BC125AT scanner", " - usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()", " - USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub", " - usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()", " - usb: free iso schedules on failed submit", " - usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler", " - usb: gadget: udc: Fix use-after-free in gadget_match_driver", " - usb: gadget: f_printer: take kref only for successful open", " - USB: idmouse: fix use-after-free on disconnect race", " - USB: ldusb: fix use-after-free on disconnect race", " - USB: iowarrior: fix use-after-free on disconnect", " - USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD", " - USB: legousbtower: fix use-after-free on disconnect race", " - usb: sl811-hcd: disable controller wakeup on remove", " - USB: storage: include US_FL_NO_SAME in quirks mask", " - USB: misc: uss720: unregister parport on probe failure", " - usb: mtu3: unmap request DMA on queue failure", " - USB: serial: keyspan_pda: fix information leak", " - USB: serial: option: add Telit Cinterion FE990D50 compositions", " - USB: serial: digi_acceleport: fix broken rx after throttle", " - USB: serial: digi_acceleport: fix hard lockup on disconnect", " - USB: serial: digi_acceleport: fix write buffer corruption", " - USB: ulpi: fix memory leak on registration failure", " - USB: usb-storage: ene_ub6250: restore media-ready check", " - usbip: tools: support SuperSpeedPlus devices", " - usbip: vudc: fix NULL deref in vep_dequeue()", " - usb: typec: anx7411: use devm_pm_runtime_enable()", " - usb: typec: class: drop PD lookup reference", " - usb: typec: tcpm: Validate SVID index in svdm_consume_modes()", " - usb: typec: ucsi: Invert DisplayPort role assignment", " - usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt", " mode", " - usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove", " - usb: typec: ucsi: cancel pending work on system suspend", " - iio: temperature: ltc2983: Fix n_wires default bypassing rotation check", " - PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining", " - udf: validate free block extents against the partition length", " - udf: validate VAT header length against the VAT inode size", " - udf: validate sparing table length as an entry count, not a byte count", " - hwrng: jh7110 - fix refcount leak in starfive_trng_read()", " - dm-ioctl: report an error if a device has no table", " - nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace", " disks", " - btrfs: do not trim a device which is not writeable", " - partitions: aix: bound the pp_count scan to the ppe array", " - isofs: bound Rock Ridge symlink components to the SL record", " - crypto: af_alg - Remove zero-copy support from skcipher and aead", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps again", " - crypto: ecc - Fix carry overflow in vli multiplication", " - crypto: pcrypt - restore callback for non-parallel fallback", " - crypto: drbg - Fix returning success on failure in CTR_DRBG", " - crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels", " - crypto: drbg - Fix the fips_enabled priority boost", " - crypto: qat - validate RSA CRT component lengths", " - crypto: talitos - use dma_sync_single_for_cpu() before reading", " descriptor header", " - crypto: talitos - add chaining of arbitrary number of descriptor for the", " SEC1", " - crypto: talitos - move dma unmapping code in flush_channel() into a", " standalone dma_unmap_request() function", " - crypto: talitos - move dma mapping code in talitos_submit() into a", " standalone dma_map_request() function", " - crypto: talitos - move code in current_desc_hdr() into a standalone", " function", " - crypto: talitos/hash - prepare SEC1 descriptor chaining, remove", " additional descriptor", " - crypto: talitos/hash - use descriptor chaining for SEC1 instead of", " workqueue", " - crypto: talitos/hash - drop workqueue mechanism for SEC1", " - crypto: talitos/hash - rename first_desc/last_desc to", " first_request/last_request", " - crypto: talitos/hash - remove useless wrapper", " - crypto: talitos/hash - fix SEC2 64k - 1 ahash request limitation", " - arm64: fpsimd: Fix type mismatch in sme_{save,load}_state()", " - spi: fsl-lpspi: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - spi: fsl-lpspi: terminate the RX channel on TX prepare failure path", " - EDAC/i10nm: Don't fail probing if ADXL is missing", " - watchdog: apple: Add \"apple,t8103-wdt\" compatible", " - tracing: Prevent out-of-bounds read in glob matching", " - NFSv4: include MAY_WRITE in open permission mask for O_TRUNC", " - module: decompress: check return value of module_extend_max_pages()", " - exfat: bound uniname advance in exfat_find_dir_entry()", " - NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()", " - KVM: VMX: Refresh GUEST_PENDING_DBG_EXCEPTIONS.BS on all injected #DBs", " - KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest", " mode", " - udmabuf: fix DMA direction mismatch in release_udmabuf()", " - i2c: core: fix adapter deregistration race", " - i2c: mpc: Fix timeout calculations", " - i2c: stm32f7: truncate clock period instead of rounding it", " - Input: synaptics-rmi4 - unregister function handlers on physical driver", " registration failure", " - Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count", " - Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count", " - Input: elan_i2c - prevent division by zero and arithmetic underflow", " - Input: goodix - clamp the device-reported contact count", " - Input: iforce - bound the device-reported force-feedback effect index", " - Input: mms114 - fix touch indexing for MMS134S and MMS136", " - Input: touchwin - reset the packet index on every complete packet", " - Input: mms114 - reject an oversized device packet size", " - Input: maplemouse - fix NULL pointer dereference in open()", " - Input: mms114 - fix multi-touch slot corruption", " - Input: maple_keyb - set driver data before registering input device", " - Input: maplemouse - set driver data before registering input device", " - Input: maplecontrol - set driver data before registering input device", " - RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", " - fuse: fix device node leak in cuse_process_init_reply()", " - fuse: re-lock request before returning from fuse_ref_folio()", " - smb: client: reject overlapping data areas in SMB2 responses", " - xfs: fail recovery on a committed log item with no regions", " - xfs: resample the data fork mapping after cycling ILOCK", " - smb/server: do not require delete access for non-replacing links", " - sched/fair: Only update stats for allowed CPUs when looking for dst", " group", " - KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU", " - KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove CRYPTO_DEV_SUN4I_SS_PRNG", " - crypto: crypto4xx - Remove ahash-related code", " - bpf: Support for hardening against JIT spraying", " - x86/bugs: Enable IBPB flush on BPF JIT allocation", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix sequence number when no EOF", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - dt-bindings: power: imx93: Add MIPI PHY power domain", " - serial: msm: Disable DMA for kernel console UART", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: Fix further netns teardown to cancel the preallocation charger", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/amdgpu: fix integer overflow in amdgpu_gem_align_pitch()", " - drm/radeon: fix integer overflow in radeon_align_pitch()", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " - libbpf: Report error when a negative kprobe offset is specified", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg", " warning", " - wifi: cfg80211: fix grammar in MLO group key error message", " - arm64: tegra: Fix Tegra234 MGBE PTP clock", " - dt-bindings: pinctrl: nvidia,tegra234: Add missing required block", " - drm/amdkfd: Validate CRIU-restored IDs before idr_alloc", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sama5d4_wdt: Fix WDDIS detection on SAM9X60 and SAMA7G5", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - media: v4l2-common: Add YUV24 format info", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " - dlm: fix add msg handle in send_queue ordered", " - nilfs2: fix backing_dev_info reference leak", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - evm: terminate and bound the evm_xattrs read buffer", " - thermal: hwmon: Fix critical temperature attribute removal", " - clk: scpi: Unregister child clock providers on remove", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - spi: hisi-kunpeng: Use dev_err_probe() for host registration failure", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/srpt: fix integer overflow in immediate data length check", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - driver core: Use mod_delayed_work to prevent lost deferred probe work", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - bus: sunxi-rsb: Always check register address validity", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: seq: midi: Serialize output teardown with event_input", " - pinctrl: cs42l43: Fix polarity on debounce", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " - drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X", " client is registered", " - drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove", " - gpu: host1x: Allow entries in BO caches to be freed", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - gpu: host1x: Fix iommu_map_sgtable() return value check", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Harden parse_vma_segs() path parsing", " - libbpf: Fix UAF in strset__add_str()", " - dax/kmem: account for partial discontiguous resource upon removal", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - rpmsg: use generic driver_override infrastructure", " - md/raid10: reset read_slot when reusing r10bio for discard", " - RDMA/siw: bound Read Response placement to the RREAD length", " - block: skip sync_blockdev() on surprise removal in bdev_mark_dead()", " - crypto: algif_skcipher - force synchronous processing", " - crypto: crypto4xx - Remove insecure and unused rng_alg", " - crypto: hisi-trng - Remove crypto_rng interface", " - bpf: Restrict JIT predictor flush to cBPF", " - bpf: Skip redundant IBPB in pack allocator", " - bpf: Prefer packs that won't trigger an IBPB flush on allocation", " - bpf: Prefer dirty packs for eBPF allocations", " - clk: scmi: Fix clock rate rounding", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - bitops: use common function parameter names", " - media: rockchip: rga: fix too small buffer size", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - scsi: ufs: Fix wrong value printed in unexpected UPIU response case", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " - mm/fake-numa: fix under-allocation detection in uniform split", " - ext2: fix ignored return value of generic_write_sync()", " - sched: restore timer_slack_ns when resetting RT policy on fork", " - lib/test_meminit: use && for bools", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: reject FITRIM ranges shorter than a cluster", " - ocfs2/dlm: require a ref for locking_state debugfs open", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - bpf: Check tail zero of bpf_prog_info", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - wifi: wcn36xx: fix heap overflow from oversized firmware HAL response", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " - wifi: wcn36xx: fix OOB read from short trigger BA firmware response", " - ALSA: seq: Fix partial userptr event expansion", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - scsi: target: Fix hexadecimal CHAP_I handling", " - scsi: target: Remove tcm_loop target reset handling", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " - hwspinlock: qcom: avoid uninitialized struct members", " - sched/fair: Fix cpu_util runnable_avg arithmetic", " - wifi: mt76: fix argument to ieee80211_is_first_frag()", " - wifi: mt76: mt7915: fix potential tx_retries underflow", " - wifi: mt76: mt7921: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - spi: meson-spifc: fix runtime PM leak on remove", " - ASoC: codecs: aw88261: fix incorrect masks for boost regs", " - vduse: hold vduse_lock across IDR lookup in open path", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " - vduse: Requeue failed read to send_list head", " - vhost/net: complete zerocopy ubufs only once", " - tools/virtio: check mmap return value in vringh_test", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - bonding: 3ad: fix mux port state on oper down", " - ext4: fix kernel BUG in ext4_write_inline_data_end", " - selftests/bpf: Fix bpf_iter/task_vma test", " - cxl/test: Fix integer overflow in mock LSA bounds checks", " - cxl/test: Zero out LSA backing memory to avoid leaking to user", " - of: cpu: add check in __of_find_n_match_cpu_property()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " - RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " - ASoC: fsl: fsl_audmix: Validate written enum values", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " - net/sched: cls_flow: Dont expose folded kernel pointers", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " - bridge: cfm: reject invalid CCM interval at configuration time", " - sctp: validate embedded address parameter length", " - net/sched: sch_hfsc: Don't make class passive twice", " - tipc: require net admin for TIPCv2 netlink mutators", " - tipc: prevent snt_unacked underflow on CONN_ACK", " - tipc: reject inverted service ranges from peer bindings", " - cxl/test: Add check after kzalloc() memory in alloc_mock_res()", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " - crypto: rng - Free default RNG on module exit", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - power: supply: core: fix supplied_from allocations", " - handshake: Require admin permission for DONE command", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - net: wwan: t7xx: check skb_clone in control TX", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - netfilter: nf_conncount: callers must hold rcu read lock", " - ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait()", " - cifs: remove all cifs files before kill super", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - tipc: fix UAF in tipc_l2_send_msg()", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - ionic: Fix check in ionic_get_link_ext_stats", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - coresight: cti: Fix DT filter signals silently ignored", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - PCI/ASPM: Don't reconfigure ASPM entering low-power state", " - PCI: Introduce named defines for PCI ROM", " - PCI: Check ROM header and data structure addr before accessing", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - mailbox: mtk-adsp: fix UAF during device teardown", " - staging: most: video: avoid double free on video register failure", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " - iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " - iio: tcs3472: power down chip on probe failure", " - clk: at91: keep securam node alive while mapping it", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - fs/ntfs3: add bounds check to run_get_highest_vcn()", " - fs/ntfs3: fix mount failure on 64K page-size kernels", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - pNFS/filelayout: fix cheking if a layout is striped", " - xprtrdma: Remove temp allocation of rpcrdma_rep objects", " - xprtrdma: Avoid 250 ms delay on backlog wakeup", " - xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot", " - xprtrdma: Post receive buffers after RPC completion", " - xprtrdma: Use sendctx DMA state for Send signaling", " - xprtrdma: Decouple req recycling from RPC completion", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - nfs: keep PG_UPTODATE clear after read errors in page groups", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Fix bcall rep leak and unbounded peek", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - apparmor: fix rawdata_f_data implicit flex array", " - apparmor: fix potential UAF in aa_replace_profiles", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - sparc: led: avoid trimming a newline from empty writes", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - spi: dw: fix wrong BAUDR setting after resume", " - xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO", " path", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " - PCI: iproc: Restore .map_irq() for the platform bus driver", " - spi: rpc-if: Use correct device for hardware reinitialization on resume", " - virtio-net: fix len check in receive_big()", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - flow_dissector: check device type before reading ETH_ADDRS", " - ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: Fix data race between add and dump in all hash types", " - netfilter: ipset: annotate \"pos\" for concurrent readers/writers", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash", " types", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - irqchip/crossbar: Fix parent domain resource leak", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - net: marvell: prestera: initialize err in prestera_port_sfp_bind", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " - net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths", " - octeontx2-af: mcs: Fix unsupported secy stats read", " - octeontx2-pf: Clear stats of all resources when freeing resources", " - octeontx2-pf: mcs: Fix mcs resources free on PF shutdown", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: Fix stack slot index in nospec checks", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()", " - ice: fix AQ error code comparison in ice_set_pauseparam()", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - ipv4: fib: Don't ignore error route in local/main tables.", " - bpf, lsm: Add disabled BPF LSM hook list", " - bpf: Disable xfrm_decode_session hook attachment", " - netfilter: nf_nat: avoid invalid nat_net pointer use on failed", " nf_nat_init()", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - netfilter: nft_compat: ebtables emulation must reject non-bridge targets", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - NTB: epf: Report 0-based doorbell vector via ntb_db_event()", " - NTB: epf: Fix doorbell bitmask and IRQ vector handling", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - net, bpf: check master for NULL in xdp_master_redirect()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - net: mvneta: re-enable percpu interrupt on resume", " - net: sungem: fix probe error cleanup", " - net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - net: enetc: check the number of BDs needed for xdp_frame", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - apparmor: check label build before no_new_privs test", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - net/sched: sch_teql: Introduce slaves_lock to avoid race condition and", " UAF", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - cxgb4: Fix decode strings dump for T6 adapters", " - virtio_net: disable cb when NAPI is busy-polled", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - ksmbd: reject undersized DACLs before parsing ACEs", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - pinctrl: meson: restore non-sleeping GPIO access", " - net/sched: hhf: clear heavy-hitter state on reset", " - fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid", " - afs: Fix error code in afs_extract_vl_addrs()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix vllist leak", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " - afs: Fix unchecked-length string display in debug statement", " - minix: avoid overflow in bitmap block count calculation", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: convert READ_ONCE(*ptep) to ptep_get(ptep)", " - arm64/mm: convert set_pte_at() to set_ptes(..., 1)", " - arm64/mm: convert ptep_clear() to ptep_get_and_clear()", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - selftests/hid: convert the hid_bpf selftests with struct_ops", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - gue: validate REMCSUM private option length", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " - amt: fix size calculation in amt_get_size()", " - Bluetooth: 6lowpan: hold L2CAP conn across debugfs control", " - Bluetooth: MGMT: Fix adv monitor add failure cleanup", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - ring-buffer: Fix event length with forced 8-byte alignment", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: move functions to avoid forward definitions", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " - ipv6: mcast: Replace locking comments with lockdep annotations.", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " - s390/zcrypt: Remove the empty file", " - cifs: validate DFS referral string offsets", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " - dm era: fix NULL pointer dereference in metadata_open()", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " - selftests/net: fix EVP_MD_CTX leak in tcp_mmap", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - octeontx2-af: fix VF bringup affecting PF promiscuous state", " - smb: client: fix overflow in passthrough ioctl bounds check", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " - ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put", " - ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc", " - ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get", " - ASoC: SOF: topology: validate vendor array size before parsing", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " - net: atm: reject out-of-range traffic classes in QoS validation", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " - fbdev: vesafb: fix memory leak in vesafb_probe()", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " - ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get", " - ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Release reserved memory on cleanup", " - ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_cluster: reject template conntracks in hash match", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - netfilter: nf_nat_sip: reload possible stale data pointer", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " - netfilter: ecache: fix inverted time_after() check", " - netfilter: xt_nat: reject unsupported target families", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - selinux: check connect-related permissions on TCP Fast Open", " - leds: uleds: Fix potential buffer overread", " - mfd: sm501: Fix reference leak on failed device registration", " - tools/power/x86/intel-speed-select: Harden daemon pidfile open", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " - x86/boot: Reject too long acpi_rsdp= values", " - perf/x86/amd/lbr: Fix kernel address leakage", " - s390/perf_cpum_cf: Add missing array_index_nospec() to", " __hw_perf_event_init()", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: bla: reacquire gw address after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: tt: avoid request storms during pending request", " - batman-adv: fix VLAN priority offset", " - batman-adv: frag: free unfragmentable packet", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: tt: prevent TVLV OOB check overflow", " - cifs: invalidate cfid on unlink/rename/rmdir", " - mfd: tps6586x: Fix OF node refcount", " - HID: playstation: validate num_touch_reports in DualShock 4 reports", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " - nvdimm/btt: Free arenas on btt_init() error paths", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - mm/damon/core: make charge_addr_from aware of end-address exclusivity", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " - fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " - riscv: cacheinfo: Fix node reference leak in populate_cache_leaves", " - mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs()", " - mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error", " - proc: only bump parent nlink when registering directories", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - mtd: rawnand: pl353: fix probe resource allocation", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " - mtd: rawnand: fix condition in 'nand_select_target()'", " - ocfs2: avoid moving extents to occupied clusters", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " - ocfs2: add journal NULL check in ocfs2_checkpoint_inode()", " - ocfs2: reject dinodes with non-canonical i_mode type", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " - fpga: dfl: add bounds check in dfh_get_param_size()", " - bus: mhi: ep: Protect mhi_ep_handle_syserr() in the error path", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - fpga: microchip-spi: fix zero header_size OOB read in", " mpf_ops_parse_header()", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86/amd/pmc: Check for intermediate wakeup in function", " - platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops", " - platform/x86/amd/pmc: Add delay_suspend module parameter", " - smb: client: use kvzalloc() for megabyte buffer in simple fallocate", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - ice: fix ice_init_link() error return preventing probe", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - tpm: Make the TPM character devices non-seekable", " - time: Fix off-by-one in compat settimeofday() usec validation", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " - sctp: validate STALE_COOKIE cause length before reading staleness", " - nvmet-rdma: handle inline data with a nonzero offset", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " - can: bcm: add missing rcu list annotations and operations", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - net: sparx5: unregister blocking notifier on init failure", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " - dm era: fix out-of-bounds memory access for non-zero start sector", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-ioctl: fix a possible overflow in list_version_get_info", " - dm-log: fix a bitset_size overflow on 32bit machines", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm_early_create: fix freeing used table on dm_resume failure", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - scsi: sg: Report request-table problems when any status is set", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - validate control endpoint type", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - Input: ims-pcu - fix race condition in reset_device sysfs callback", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " - net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio-f7188x: Add support for NCT6126D version B", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: wwan: t7xx: destroy DMA pool on CLDMA late init failure", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - net: ena: clean up XDP TX queues when regular TX setup fails", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " - ieee802154: admin-gate legacy LLSEC dump operations", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " - batman-adv: ensure minimal ethernet header on TX", " - batman-adv: clean untagged VLAN on netdev registration failure", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - espintcp: use sk_msg_free_partial to fix partial send", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: mpfs: fix counter upload completion condition", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - net: liquidio: fix BAR resource leak on PF number failure", " - hwmon: (occ) unregister sysfs devices outside occ lock", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - net: lan743x: Initialize eth_syslock spinlock before use", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - net: wwan: iosm: bound device offsets in the MUX downlink decoder", " - hwmon: (asus_atk0110) Check package count before accessing element", " - riscv: probes: save original sp in rethook trampoline", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - drbd: reject data replies with an out-of-range payload size", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " - pmdomain: imx: Fix i.MX8MP power notifier", " - pmdomain: imx: Fix i.MX8MP VC8000E power up sequence", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - Bluetooth: btrtl: validate firmware patch bounds", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - memstick: ms_block: reject a card that reports too many blocks", " - ipvs: fix more places with wrong ipv6 transport offsets", " - ipvs: reload ip header after head reallocation", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: mac80211: free ack status frame on TX header build failure", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " - mtd: onenand: samsung: report DMA completion timeouts", " - mtd: mchp23k256: use SPI match data for chip caps", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " - perf/x86/amd/brs: Fix kernel address leakage", " - ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup", " - ACPI: bus: Introduce devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Use devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Fix possible deadlock and missing notifications", " - iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - iio: invensense: remove redundant initialization of variable period", " - iio: invensense: fix timestamp glitches when switching frequency", " - iio: imu: inv_icm42600: stabilized timestamp in interrupt", " - iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading", " - iio: pressure: mpl115: fix runtime PM leak on read error", " - bitops: make BYTES_TO_BITS() treewide-available", " - iio: common: st_sensors: honour channel endianness in read_axis_data", " - ALSA: aoa: check snd_ctl_new1() return value", " - PCI: altera: Fix resource leaks on probe failure", " - vfio/mlx5: Fix racy bitfields and tighten struct layout", " - PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling", " - PCI: controller: Use dev_fwnode() instead of of_fwnode_handle()", " - PCI: mediatek: Convert bool to single quirks entry and bitmap", " - PCI: mediatek: Use generic MACRO for TPVPERL delay", " - PCI: mediatek: Fix IRQ domain leak when port fails to enable", " - PCI: Prevent resource tree corruption when BAR resize fails", " - PCI: Free saved list without holding pci_bus_sem", " - PCI: Fix restoring BARs on BAR resize rollback path", " - PCI: Add kerneldoc for pci_resize_resource()", " - PCI: Move Resizable BAR code to rebar.c", " - PCI: Skip Resizable BAR restore on read error", " - staging: rtl8723bs: core: move constants to right side in comparison", " - staging: rtl8723bs: fix spaces around binary operators", " - staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),", " rtw_get_wapi_ie(), and rtw_get_wps_attr()", " - crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()", " - Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref", " - mm/shrinker: do not hold RCU lock in shrinker_debugfs_count_show()", " - coresight: etb10: restore atomic_t for shared reading state", " - gpio: sch: use raw_spinlock_t in the irq startup path", " - media: nxp: imx8-isi: Convert to platform remove callback returning void", " - media: nxp: imx8-isi: use devm_pm_runtime_enable() to simplify code", " - media: nxp: imx8-isi: Fix use-after-free on remove", " - netfilter: ebtables: Use vmalloc_array() to improve code", " - netfilter: ebtables: zero chainstack array", " - Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - smb: client: Improve unlocking of a mutex in cifs_get_swn_reg()", " - smb: client: resolve SWN tcon from live registrations", " - ksmbd: use opener credentials for FSCTL mutations", " - ksmbd: centralize ksmbd_conn final release to plug transport leak", " - ksmbd: track the connection owning a byte-range lock", " - proc: rename proc_setattr to proc_nochmod_setattr", " - proc: protect ptrace_may_access() with exec_update_lock (FD links)", " - writeback: fix race between cgroup_writeback_umount() and", " inode_switch_wbs()", " - perf/x86/intel/uncore: Defer ADL global PMON enable to enable_box()", " - HID: add haptics page defines", " - HID: multitouch: fix out-of-bounds bit access on mt_io_flags", " - mm/slab: do not limit zeroing to orig_size when only red zoning is", " enabled", " - seqlock: Introduce scoped_seqlock_read()", " - seqlock: Change do_task_stat() to use scoped_seqlock_read()", " - proc: protect ptrace_may_access() with exec_update_lock (part 1)", " - treewide: Switch/rename to timer_delete[_sync]()", " - HID: appleir: fix UAF on pending key_up_timer in remove()", " - serial: 8250_mid: Disable DMA for selected platforms", " - hfs/hfsplus: prevent getting negative values of offset/length", " - hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length", " - bpf: Consistently use bpf_rcu_lock_held() everywhere", " - bpf: Allow LPM map access from sleepable BPF programs", " - usb: iowarrior: remove inherent race with minor number", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - usb: typec: tcpm: Fix VDM type for Enter Mode commands", " - crypto: atmel - Drop explicit initialization of struct", " i2c_device_id::driver_data to 0", " - crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A", " - usb: gadget: f_fs: initialize reset_work at allocation time", " - nvmet: return DHCHAP status codes from nvmet_setup_auth()", " - nvmet-auth: validate reply message payload bounds against transfer", " length", " - usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile", " - btrfs: check and set EXTENT_DELALLOC_NEW before clearing EXTENT_DELALLOC", " - crypto: qat - fix restarting state leak on allocation failure", " - audit: add audit_log_nf_skb helper function", " - audit: fix potential integer overflow in audit_log_n_hex()", " - regulator: scmi: Simplify with scoped for each OF child loop", " - regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()", " - mm: do file ownership checks with the proper mount idmap", " - exfat: move free cluster out of exfat_init_ext_entry()", " - exfat: remove unnecessary read entry in __exfat_rename()", " - exfat: rename argument name for exfat_move_file and exfat_rename_file", " - exfat: add exfat_get_dentry_set_by_ei() helper", " - exfat: move exfat_chain_set() out of __exfat_resolve_path()", " - exfat: preserve benign secondary entries during rename and move", " - btrfs: fix false IO failure after falling back to buffered write", " - btrfs: fix incorrect buffered IO fallback for append direct writes", " - Bluetooth: hci_core: Enable buffer flow control for SCO/eSCO", " - Bluetooth: separate CIS_LINK and BIS_LINK link types", " - Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - seqlock: fix scoped_seqlock_read kernel-doc", " - Bluetooth: hci_core: Remove check of BDADDR_ANY in", " hci_conn_hash_lookup_big_state", " - Bluetooth: hci_sync: Fix attempting to send HCI_Disconnect to BIS handle", " - Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote", " netdev", " - selftests/hid: ensure CKI can compile our new tests on old kernels", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error harder", " - Bluetooth: btmtk: remove #ifdef around declarations", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - jiffies: Define secs_to_jiffies()", " - jiffies: Cast to unsigned long in secs_to_jiffies() conversion", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - tools/testing: add linux/args.h header and fix radix, VMA tests", " - selftests/bpf: Add simple strscpy() implementation", " - bcachefs: avoid truncating fiemap extent length", " - gpio: rockchip: change the GPIO version judgment logic", " - gpio: rockchip: teardown bugs and resource leaks", " - gpio: rockchip: fix generic IRQ chip leak on remove", " - NFSv4/flexfiles: Remove cred local variable dependency", " - iio: resolver: ad2s1210: notify trigger and clear state on fault read", " error", " - iio: temperature: Build mlx90635 with CONFIG_MLX90635", " - vfio: Remove device debugfs before releasing devres", " - PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000", " series", " - netpoll: fix a use-after-free on shutdown path", " - mm: shrinker: fix shrinker_info teardown race with expansion", " - NFSv4/flexfiles: Add data structure support for striped layouts", " - mm/khugepaged: write all dirty file folios when collapsing", " - platform/x86: intel-hid: Protect ACPI notify handler against recursion", " - Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled", " - Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()", " - fs/ntfs3: rename ni_readpage_cmpr into ni_read_folio_cmpr", " - ksmbd: use __GFP_RETRY_MAYFAIL", " - ksmbd: use opener credentials for ADS I/O", " - cpufreq: Make cpufreq_driver->exit() return void", " - cpufreq: qcom-cpufreq-hw: Fix possible double free", " - nvme: target: rdma: fix ndev refcount leak on queue connect", " - nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page", " - crypto: qat - keep VFs enabled during reset", " - crypto: qat - notify fatal error before AER reset preparation", " - crypto: qat - protect service table iterations with service_lock", " - selftests/mm: pagemap_ioctl: use the correct page size for", " transact_test()", " - iommufd: Set upper bounds on cache invalidation entry_num and entry_len", " - iommu/amd: Don't split flush for amd_iommu_domain_flush_all()", " - dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning", " - i2c: core: fix adapter probe deferral loop", " - xfs: fix null pointer dereference in tracepoint", " - xfs: don't wrap around quota ids in dqiterate", " - xfs: clamp timestamp nanoseconds correctly", " - xfs: don't zap bmbt forks if they are MAXLEVELS tall", " - iommu/vt-d: Clear Present bit before tearing down context entry", " - iommu: Pass old domain to set_dev_pasid op", " - iommu/vt-d: Cleanup intel_context_flush_present()", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " - vsock/virtio: bind uarg before filling zerocopy skb", " - iommu/amd: Use maximum Event log buffer size when SNP is enabled on", " Family 0x19", " - iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family", " 0x19", " - net: dropreason: Gather SOCKET_ drop reasons.", " - af_unix: Set drop reason in unix_release_sock().", " - af_unix: Set drop reason in manage_oob().", " - af_unix: Set drop reason in unix_stream_read_skb().", " - af_unix/scm: fix whitespace errors", " - af_unix: Don't hold unix_state_lock() in __unix_dgram_recvmsg().", " - af_unix: Don't check SOCK_DEAD in unix_stream_read_skb().", " - af_unix: Don't use skb_recv_datagram() in unix_stream_read_skb().", " - af_unix: Drop all SCM attributes for SOCKMAP.", " - time/jiffies: Change register_refined_jiffies() to void __init", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - media: uvcvideo: Do not add clock samples with small sof delta", " - serial: max310x: replace bare use of 'unsigned' with 'unsigned int'", " (checkpatch)", " - serial: max310x: implement gpio_chip::get_direction()", " - drm/gpuvm: Do not prepare NULL objects", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - soc: xilinx: Shutdown and free rx mailbox channel", " - crypto: qat - fix heartbeat error injection", " - memory: tegra: Wire up system sleep PM ops", " - drm/gpuvm: take refcount on DRM device", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - RDMA/hns: Initialize seqfile before creating file", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - RDMA/hns: Fix log flood after cmd_mbox failure", " - net: introduce page_frag_cache_drain()", " - nvmet-tcp: fix page fragment cache leak in error path", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - driver core: Use system_percpu_wq instead of system_wq", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - x86/cpu/amd: Provide a separate accessor for Node ID", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - netfilter: nfnetlink_cthelper: use {READ,WRITE}_ONCE for accessing", " helper flags", " - netfilter: synproxy: drop packets if timestamp adjustment fails", " - netfilter: synproxy: adjust duplicate timestamp options", " - netfilter: synproxy: fix unaligned memory access in timestamp adjustment", " - RDMA/siw: Fix endpoint/socket association handling", " - riscv: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - virtio_console: read size from config space during device init", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - net: dsa: qca8k: fix led devicename when using external mdio bus", " - ALSA: seq: Drop superfluous filter argument of get_event_dest_client()", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - dpll: add reference-sync netlink attribute", " - dpll: move xa_erase() call in to match dpll_pin_alloc() error path order", " - dpll: add reference sync get/set", " - dpll: Allow associating dpll pin with a firmware node", " - dpll: Add notifier chain for dpll events", " - dpll: Support dynamic pin index allocation", " - dpll: Enhance and consolidate reference counting logic", " - dpll: fix stale iteration in dpll_pin_on_pin_unregister()", " - dpll: send delete notification before unregister in on-pin rollback", " - dpll: emit per-dpll delete notifications in dpll_pin_on_pin_unregister()", " - dpll: guard sync-pair removal on full pin unregister", " - dpll: balance create/delete notifications in __dpll_pin_(un)register", " - landlock: Fix unmarked concurrent access to socket family", " - selftests/bpf: Fix typo in verify_umulti_link_info", " - udf: fix nls leak on udf_fill_super() failure", " - mfd: rsmu: Fix page register setup", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: split ep_insert() into alloc + register stages", " - eventpoll: extract ep_deliver_event() from ep_send_events()", " - eventpoll: wrap EP_UNACTIVE_PTR in typed sentinel helpers", " - eventpoll: rename epi->next and txlist for clarity", " - eventpoll: Fix epoll_wait() report false negative", " - gpiolib: acpi: Only trigger ActiveBoth interrupts on boot", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - PCI: meson: Add missing remove callback", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - workqueue: Add new WQ_PERCPU flag", " - i3c: master: add WQ_PERCPU to alloc_workqueue users", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - xfrm: Fix xfrm state cache insertion race", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - netfilter: ipset: make sure gc is properly stopped", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: hugetlb_reparenting_test: do not unmount", " - selftests/mm: save and restore nr_hugepages value", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - ipv6: annotate data-races around cnf.forwarding", " - ipv6/addrconf: annotate data-races around devconf fields (II)", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_info", " - ice: dpll: fix memory leak in ice_dpll_init_info error paths", " - net: bnxt: use ethtool string helpers", " - eth: bnxt: gather and report HW-GRO stats", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - ipv6: Add __in6_dev_get_rtnl_net().", " - octeontx2-af: Validate NIX maximum LFs correctly", " - udp_tunnel: remove rtnl_lock dependency", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - net: hisilicon: hns3: use ethtool string helpers", " - net: hns3: use string choices helper", " - net: hns3: use hns3_get_ae_dev() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: use hns3_get_ops() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: clear hns alarm: comparison of integer expressions of", " different signedness", " - net: hns3: unify copper port ksettings configuration path", " - net: hns3: refactor MAC autoneg and speed configuration", " - net: hns3: fix permanent link down deadlock after reset", " - net: hns3: differentiate autoneg default values between copper and fiber", " - rtnetlink: Add per-netns RTNL.", " - [Config] Set CONFIG_DEBUG_NET_SMALL_RTNL=n", " - rtnetlink: Add assertion helpers for per-netns RTNL.", " - rtnetlink: Define rtnl_net_trylock().", " - ipv6: Convert net.ipv6.conf.${DEV}.XXX sysctl to per-netns RTNL.", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Make /afs/. as well as /afs/ mountpoints", " - afs: Add rootcell checks", " - afs: Make /afs/@cell and /afs/.@cell symlinks", " - afs: Fix afs_atcell_get_link() to handle RCU pathwalk", " - afs: Remove the \"autocell\" mount option", " - afs: Change dynroot to create contents on demand", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - ovl: fix comment about locking order", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - afs: Convert comma to semicolon", " - afs: Fix double netfs initialisation in afs_root_iget()", " - drm/xe: Add warn when level can not be zero.", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - HID: bpf: Fix hid_bpf_get_data() range check", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - genirq/generic_chip: Introduce irq_domain_{alloc,remove}_generic_chips()", " - gpio: mvebu: free generic chips on unbind", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " - drm/xe: remove duplicate include", " - LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()", " - LoongArch: KVM: Check the return values for put_user()", " - LoongArch: KVM: Fix FPU register width with user access API", " - LoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr()", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - fbdev: efifb: fix memory leak in efifb_probe()", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - batman-adv: mcast: avoid OOB read of num_dests header", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()", " - fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry()", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - taskstats: retain dead thread stats in TGID queries", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - NFS: Charge unstable writes by request size, not folio size", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: make error counter atomic", " - accel/ivpu: Reject firmware log with size smaller than header", " - firmware_loader: introduce __free() cleanup hanler", " - Input: ims-pcu - fix firmware leak in async update", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - gpio: tegra: do not call pinctrl for GPIO direction", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - s390: Revert support for DCACHE_WORD_ACCESS", " - [Config] Set CONFIG_DCACHE_WORD_ACCESS=- for s390x", " - selftests: net: make busywait timeout clock portable", " - ata: libata: Use QUIRK instead of HORKAGE", " - ata: libata-core: Skip HPA resize for locked drives", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - ALSA: hda/cs35l41: Fix firmware load work teardown", " - io_uring/rw: ensure reissue path is correctly handled for IOPOLL", " - io_uring/rw: preserve partial result for iopoll", " - Bluetooth: L2CAP: Fix not tracking outstanding TX ident", " - mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless", " host", " - ksmbd_vfs_rename(): vfs_path_parent_lookup() accepts ERR_PTR() as name", " - vfs: make LAST_XXX private to fs/namei.c", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " - HID: pidff: Fix missing blank lines after declarations", " - HID: pidff: Add missing spaces", " - HID: pidff: Rework pidff_upload_effect", " - HID: pidff: Use correct effect type in effect update", " - bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()", " - USB: iowarrior: fix use-after-free on disconnect race", " - crypto: atmel-sha204a - fail on hwrng registration error in probe path", " - btrfs: concentrate the error handling of submit_one_sector()", " - btrfs: remove folio parameter from ordered io related functions", " - btrfs: remove the COW fixup mechanism", " - slab: Introduce kmalloc_obj() and family", " - slab: Introduce kmalloc_flex() and family", " - add default_gfp() helper macro and use it in the new *alloc_obj()", " helpers", " - default_gfp(): avoid using the \"newfangled\" __VA_OPT__ trick", " - slab: recognize @GFP parameter as optional in kernel-doc", " - fscrypt: Fix key setup in edge case with multiple data unit sizes", " - fscrypt: Replace mk_users keyring with simple list", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is", " uninitialized", " - rtnetlink: Make per-netns RTNL dereference helpers to macro.", " - afs: Fix afs_atcell_get_link() to check if ws_cell is unset first", " - afs: Fix afs_dynroot_readdir() to not use the RCU read lock", " - udp_tunnel: fix deadlock in udp_tunnel_nic_set_port_priv()", " - i40e: drop udp_tunnel_get_rx_info() call from i40e_open()", " - ice: drop udp_tunnel_get_rx_info() call from ndo_open()", " - Bluetooth: L2CAP: Fix regressions caused by reusing ident", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " - perf: Reject exited events as group leaders", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - proc: Fix broken error paths for namespace links", " - Upstream stable to v6.6.145, v6.12.96, v6.12.97", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2026-53365", " - vsock/virtio: fix zerocopy completion for multi-skb sends", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two", " - x86/mm: Fix check/use ordering in switch_mm_irqs_off()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192)", " - debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING", " - debugobjects: Use LD_WAIT_CONFIG instead of LD_WAIT_SLEEP", " - debugobjects: Dont call fill_pool() in early boot hardirq context", " - ARM: group is_permission_fault() with is_translation_fault()", " - ARM: allow __do_kernel_fault() to report execution of memory faults", " - ARM: fix branch predictor hardening", " - RDMA/bnxt_re: zero shared page before exposing to userspace", " - selftests/bpf: Add test to ensure kprobe_multi is not sleepable", " - bpf: Remove mark_precise_scalar_ids()", " - selftests/bpf: Tests for per-insn sync_linked_regs() precision tracking", " - selftests/bpf: Update comments find_equal_scalars->sync_linked_regs", " - hv: utils: handle and propagate errors in kvp_register", " - Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs", " - phonet: Pass ifindex to fill_addr().", " - phonet: Pass net and ifindex to phonet_address_notify().", " - scripts/sorttable: Remove unused macro defines", " - scripts/sorttable: Remove unused write functions", " - scripts/sorttable: Remove unneeded Elf_Rel", " - scripts/sorttable: Have the ORC code use the _r() functions to read", " - scripts/sorttable: Make compare_extable() into two functions", " - scripts/sorttable: Convert Elf_Ehdr to union", " - scripts/sorttable: Replace Elf_Shdr Macro with a union", " - scripts/sorttable: Convert Elf_Sym MACRO over to a union", " - scripts/sorttable: Add helper functions for Elf_Ehdr", " - scripts/sorttable: Add helper functions for Elf_Shdr", " - scripts/sorttable: Add helper functions for Elf_Sym", " - scripts/sorttable: Use uint64_t for mcount sorting", " - scripts/sorttable: Move code from sorttable.h into sorttable.c", " - scripts/sorttable: Get start/stop_mcount_loc from ELF file directly", " - scripts/sorttable: Use a structure of function pointers for elf helpers", " - arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64", " - [Config] Set configs to sort mcount_loc at boot for arm64", " - scripts/sorttable: Have mcount rela sort use direct values", " - scripts/sorttable: Always use an array for the mcount_loc sorting", " - scripts/sorttable: Zero out weak functions in mcount_loc table", " - ftrace: Update the mcount_loc check of skipped entries", " - ftrace: Have ftrace pages output reflect freed pages", " - ftrace: Do not over-allocate ftrace memory", " - ftrace: Test mcount_loc addr before calling ftrace_call_addr()", " - ftrace: Check against is_kernel_text() instead of kaslr_offset()", " - scripts/sorttable: Use normal sort if theres no relocs in the mcount", " section", " - scripts/sorttable: Allow matches to functions before function entry", " - scripts/sorttable: Fix endianness handling in build-time mcount sort", " - file: add fput() cleanup helper", " - eventpoll: use hlist_is_singular_node() in __ep_remove()", " - Revert \"ptp: add testptp mask test\"", " - Bluetooth: btmtk: validate WMT event SKB length before struct access", " - Bluetooth: btmtk: accept too short WMT FUNC_CTRL events", " - batman-adv: tp_meter: keep unacked list in ascending ordered", " - batman-adv: tp_meter: initialize dup_acks explicitly", " - batman-adv: tp_meter: initialize dec_cwnd explicitly", " - batman-adv: tp_meter: avoid window underflow", " - batman-adv: tp_meter: fix fast recovery precondition", " - batman-adv: tp_meter: handle seqno wrap-around for fast recovery", " detection", " - batman-adv: tp_meter: add only finished tp_vars to lists", " - batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE", " - batman-adv: prevent ELP transmission interval underflow", " - batman-adv: tp_meter: initialize last_recv_time during init", " - batman-adv: ensure bcast is writable before modifying TTL", " - batman-adv: fix (m|b)cast csum after decrementing TTL", " - batman-adv: frag: ensure fragment is writable before modifying TTL", " - batman-adv: frag: avoid underflow of TTL", " - batman-adv: tp_meter: annotate last_recv_time access with", " READ/WRITE_ONCE", " - batman-adv: tp_meter: prevent parallel modifications of last_recv", " - batman-adv: tp_meter: handle overlapping packets", " - batman-adv: tt: don't merge change entries with different VIDs", " - batman-adv: tt: track roam count per VID", " - batman-adv: dat: prevent false sharing between VLANs", " - batman-adv: tvlv: enforce 2-byte alignment", " - batman-adv: tvlv: avoid race of cifsnotfound handler state", " - inet: add indirect call wrapper for getfrag() calls", " - err.h: use __always_inline on all error pointer helpers", " - wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S", " - wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor", " - wifi: rtw88: increase TX report timeout to fix race condition", " - wifi: iwlwifi: mvm: fix race condition in PTP removal", " - f2fs: fix to round down start offset of fallocate for pin file", " - f2fs: keep atomic write retry from zeroing original data", " - MIPS: DEC: Prevent initial console buffer from landing in XKPHYS", " - fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode", " - nfsd: check get_user() return when reading princhashlen", " - NFS: Prevent resource leak in nfs_alloc_server()", " - serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero", " - wifi: mt76: mt7921: avoid undesired changes of the preset regulatory", " domain", " - ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()", " - xfs: fix error returns in CoW fork repair", " - locking/mutex: Remove wakeups from under mutex::wait_lock", " - net: ipv6: Make udp_tunnel6_xmit_skb() void", " - Revert \"PCI: qcom: Advertise Hotplug Slot Capability with no Command", " Completion support\"", " - KVM: SEV: Ignore MMIO requests of length '0'", " - mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program", " - mtd: spi-nor: macronix: add support for mx66{l2, u1}g45g", " - LoongArch: Report dying CPU to RCU in stop_this_cpu()", " - MIPS: smp: report dying CPU to RCU in stop_this_cpu()", " - locking: rtmutex: Fix wake_q logic in task_blocks_on_rt_mutex", " - bonding: annotate data-races arcound churn variables", " - Upstream stable to v6.6.144, v6.12.95", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53389", " - net/tcp-ao: fix use-after-free of key in del_async path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53393", " - nfsd: reset write verifier on deferred writeback errors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53400", " - i2c: core: fix adapter registration race", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63806", " - KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with", " get_unaligned()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63940", " - KVM: SEV: Ignore Port I/O requests of length '0'", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53387", " - iio: light: veml6075: add bounds check to veml6075_it_ms index", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53070", " - sctp: disable BH before calling udp_tunnel_xmit_skb()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43216", " - net: Drop the lock in skb_may_tx_timestamp()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64244", " - drivers/base/memory: set mem->altmap after successful device", " registration", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53384", " - serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53390", " - ksmbd: fix out-of-bounds read in smb_check_perm_dacl()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53391", " - NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53397", " - nfsd: fix posix_acl leak on SETACL decode failure", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64245", " - fbdev: modedb: fix a possible UAF in fb_find_mode()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53403", " - fbdev: Fix fb_new_modelist to prevent null-ptr-deref in", " fb_videomode_to_var", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64246", " - power: reset: linkstation-poweroff: fix use-after-free in the", " linkstation_poweroff_init()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63794", " - KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64247", " - KVM: x86: hyper-v: Bound the bank index when querying sparse banks", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63795", " - 9p: avoid putting oldfid in p9_client_walk() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63796", " - ocfs2: reject oversized group bitmap descriptors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63797", " - rpmsg: char: Fix use-after-free on probe error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64249", " - fpga: region: fix use-after-free in child_regions_with_firmware()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63798", " - irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup", " on remove", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63801", " - tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63802", " - blk-cgroup: fix UAF in __blkcg_rstat_flush()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63803", " - hdlc_ppp: sync per-proto timers before freeing hdlc state", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63804", " - gfs2: fix use-after-free in gfs2_qd_dealloc", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63809", " - bpf: use kvfree() for replaced sysctl write buffer", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63812", " - f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63814", " - f2fs: validate ACL entry sizes in f2fs_acl_from_disk()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63817", " - f2fs: validate compress cache inode only when enabled", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63821", " - wifi: rtw88: usb: fix memory leaks on USB write failures", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63822", " - wifi: ath11k: fix warning when unbinding", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63823", " - keys: Pin request_key_auth payload in instantiate paths", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63824", " - KEYS: fix overflow in keyctl_pkey_params_get_2()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63826", " - fbdev: fix use-after-free in store_modes()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64254", " - NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG", " share BAR", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63827", " - apparmor: fix use-after-free in rawdata dedup loop", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63828", " - apparmor: mediate the implicit connect of TCP fast open sendmsg", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63830", " - net: skmsg: preserve sg.copy across SG transforms", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63831", " - mac802154: llsec: add skb_cow_data() before in-place crypto", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53361", " - af_unix: Set gc_in_progress to true in unix_gc().", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63833", " - ntfs3: reject direct userspace writes to reserved $LX* xattrs", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53366", " - ipv4: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53362", " - ipv6: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63834", " - batman-adv: tp_meter: restrict number of unacked list entries", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63835", " - batman-adv: v: prevent OGM aggregation on disabled hardif", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63836", " - batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63807", " - KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping", " level", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53381", " - virtiofs: fix UAF on submount umount", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53382", " - media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53383", " - ksmbd: reject non-VALID session in compound request branch", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53385", " - vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent", " vcs_write", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53388", " - fuse: re-lock request before replacing page cache folio", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53157", " - net: phonet: free phonet_device after RCU grace period", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53163", " - locking/rtmutex: Skip remove_waiter() when waiter is not enqueued", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2025-23131", " - dlm: prevent NPD when writing a positive value to event_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-46252", " - regulator: core: fix locking in regulator_resolve_supply() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52928", " - af_unix: Reject SIOCATMARK on non-stream sockets", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43010", " - bpf: Reject sleepable kprobe_multi programs at attach time", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53325", " - agp/amd64: Fix broken error propagation in agp_amd64_probe()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64188", " - net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64191", " - i2c: stub: Reject I2C block transfers with invalid length", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53327", " - debugobjects: Do not fill_pool() if pi_blocked_on", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52909", " - ip6_vti: set netns_immutable on the fallback device.", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53167", " - fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios", "" ], "package": "linux", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 11:03:24 +0200" }, { "cves": [ { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-146.146 -proposed tracker (LP: #2166353)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", "", " * Bluetooth fails to initialize due to a kernel NULL pointer error", " (LP: #2165873)", " - Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c", "", " * Dell Precision fails to shutdown when HDMI display is connected (22.04", " HWE) (LP: #2164507)", " - drm/i915/vbt: Add fields dedicated_external and dyn_port_over_tc", " - drm/i915/display: Handle dedicated external ports in", " intel_encoder_is_tc()", "", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", "", " * [SRU] HPE: Fix for UBSAN array-index-out-of-bounds (LP: #2161004)", " - x86/platform/uv: Fix UBSAN array-index-out-of-bounds", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough", " (LP: #2089306)", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Reboot machine with ext4 configured to data=journal could dump spurious", " call trace (LP: #2164716)", " - ext4: clear stale xarray tags on folios skipped during writeback", "", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", "", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796)", " - netfilter: bitwise: rename some boolean operation functions", " - netfilter: bitwise: add support for doing AND, OR and XOR directly", " - drm/fbdev-helper: Set and clear VGA switcheroo client from fb_info", " - arm64: io: Rename ioremap_prot() to __ioremap_prot()", " - Disable -Wattribute-alias for clang-23 and newer", " - netfilter: xt_NFQUEUE: prefer raw_smp_processor_id", " - drm/imx: Fix three kernel-doc warnings in dcss-scaler.c", " - pcnet32: stop holding device spin lock during napi_complete_done", " - net: Annotate sk->sk_write_space() for UDP SOCKMAP.", " - net: lan743x: permit VLAN-tagged packets up to configured MTU", " - net: fec: fix pinctrl default state restore order on resume", " - Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame()", " extension handling", " - Bluetooth: MGMT: Fix backward compatibility with userspace", " - ptp: vclock: Switch from RCU to SRCU", " - octeontx2-af: npc: Fix CPT channel mask in npc_install_flow", " - vxlan: vnifilter: send notification on VNI add", " - vxlan: vnifilter: fix spurious notification on VNI update", " - ipmi: Fix rcu_read_unlock to srcu_read_unlock in handle_read_event_rsp", " - time: Fix off-by-one in settimeofday() usec validation", " - tools/rv: Fix cleanup after failed trace setup", " - arm64: tlb: Allow XZR argument to TLBI ops", " - iomap: don't revert iov_iter on partially completed buffered writes", " - net/mlx4: avoid GCC 10 __bad_copy_from() false positive", " - r8152: handle the return value of usb_reset_device()", " - rds: mark snapshot pages dirty in rds_info_getsockopt()", " - net: mvpp2: Add metadata support for xdp mode", " - net: mvpp2: build skb from XDP-adjusted data on XDP_PASS", " - clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time", " - tracing/probes: Point the error offset correctly for eprobe argument", " error", " - mmc: litex_mmc: Use DIV_ROUND_UP for more accurate clock calculation", " - USB: serial: option: add usb-id for Dell Wireless DW5826e-m", " - ALSA: timer: Fix UAF at snd_timer_user_params()", " - drm/amd/display: Reject gpio_bitshift >= 32 in", " bios_parser_get_gpio_pin_info()", " - mm/damon/ops-common: call folio_test_lru() after folio_get()", " - ARM: socfpga: Fix OF node refcount leak in SMP setup", " - ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O", " - mptcp: fix retransmission loop when csum is enabled", " - mptcp: sockopt: check timestamping ret value", " - selftests: mptcp: add test for extra_subflows underflow on userspace PM", " - ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write", " - inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush", " - pidfd: refuse access to tasks that have started exiting harder", " - i2c: stm32f7: fix timing computation ignoring i2c-analog-filter", " - i2c: tegra: Fix NOIRQ suspend/resume", " - Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)", " - Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard", " - net/mlx5: Reorder completion before putting command entry in", " cmd_work_handler", " - net: mv643xx: fix OF node refcount", " - octeontx2-af: fix memory leak in rvu_setup_hw_resources()", " - mmc: core: Fix host controller programming for fixed driver type", " - mmc: litex_mmc: Set mandatory idle clocks before CMD0", " - mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC", " - mmc: sdhci: add signal voltage switch in sdhci_resume_host", " - slimbus: qcom-ngd-ctrl: fix OF node refcount", " - drm/amdgpu: restart the CS if some parts of the VM are still invalidated", " - fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling", " - driver core: reject devices with unregistered buses", " - mm/hugetlb: avoid false positive lockdep assertion", " - soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get()", " - ipmi:ssif: Remove unnecessary indention", " - ipmi:ssif: NULL thread on error", " - selftests: mptcp: drop nanoseconds width specifier", " - tty: serial: samsung: use u32 for register interactions", " - RDMA/umem: fix kernel-doc warnings", " - RDMA: Move DMA block iterator logic into dedicated files", " - arm64: cputype: Add NVIDIA Olympus definitions", " - arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU", " - mptcp: add-addr: always drop other suboptions", " - mptcp: fix missing wakeups in edge scenarios", " - Revert \"selftest/ptp: update ptp selftest to exercise the gettimex", " options\"", " - ARM: fix hash_name() fault", " - wifi: remove zero-length arrays", " - soc: qcom: ice: Return -ENODEV if the ICE platform device is not found", " - Bluetooth: ISO: Fix not using bc_sid as advertisement SID", " - octeontx2-pf: Fix NDC sync operation errors", " - octeontx2-af: Fix initialization of mcam's entry2target_pffunc field", " - ima: kexec: skip IMA segment validation after kexec soft reboot", " - ima: kexec: move IMA log copy from kexec load to execute", " - gpio: zynq: fix runtime PM leak on remove", " - writeback: Avoid contention on wb->list_lock when switching inodes", " - writeback: Fix use after free in inode_switch_wbs_work_fn()", " - xfrm: hold device only for the asynchronous decryption", " - KVM: VMX: Update SVI during runtime APICv activation", " - drm/xe: fix refcount leak in xe_range_fence_insert()", " - slimbus: qcom-ngd-ctrl: Fix up platform_driver registration", " - slimbus: qcom-ngd-ctrl: Fix probe error path ordering", " - slimbus: qcom-ngd-ctrl: Initialize controller resources in controller", " - slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership", " - slimbus: qcom-ngd-ctrl: Balance pm_runtime enablement for NGD", " - drm/amd/pm: fix smu13 power limit default/cap calculation", " - drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in", " set_soft_freq_limited_range", " - drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs", " - mailbox: Fix NULL message support in mbox_send_message()", " - vsock/virtio: fix skb overhead accounting to preserve full buf_alloc", " - net: introduce EXPORT_IPV6_MOD() and EXPORT_IPV6_MOD_GPL()", " - mptcp: pm: fix extra_subflows underflow on userspace PM subflow creation", " - vsock/virtio: fix skb overhead overflow on 32-bit builds", " - Upstream stable to v6.6.143, v6.12.94", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53132", " - vsock/virtio: fix potential unbounded skb queue", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53138", " - drm/amd/display: Bound VBIOS record-chain walk loops", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53140", " - drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53332", " - slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53156", " - nvmem: core: fix use-after-free bugs in error paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53202", " - accel/ivpu: Fix signed integer truncation in IPC receive", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53205", " - accel/ivpu: Add bounds checks for firmware log indices", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53210", " - tee: shm: fix shm leak in register_shm_helper()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-31663", " - xfrm: hold dev ref until after transport_finish NF_HOOK", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53220", " - netfilter: revalidate bridge ports", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53229", " - net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46203", " - spi: cadence-quadspi: fix unclocked access on unbind", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63871", " - Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53251", " - Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63869", " - wifi: mac80211: limit injected antenna index in", " ieee80211_parse_tx_radiotap", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53261", " - devlink: Release nested relation on devlink free", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53262", " - l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses", " - arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-45850", " - ipvs: skip ipv6 extension headers for csum checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53133", " - RDMA/umem: Fix truncation for block sizes >= 4G", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52908", " - RDMA: During rereg_mr ensure that REREG_ACCESS is compatible", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53199", " - hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53134", " - netfilter: nft_fib: fix stale stack leak via the OIFNAME register", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63883", " - serial: qcom_geni: fix kfifo underflow when flush precedes DMA", " completion IRQ", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64528", " - tty: serial: samsung: Remove redundant port lock acquisition in rx", " helpers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53329", " - drm/amd/display: Use krealloc_array() in dal_vector_reserve()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53135", " - drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53136", " - drm/amd/display: Clamp VBIOS HDMI retimer register count to array size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53137", " - drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53143", " - drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on", " GFX11", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53144", " - drm/amdkfd: fix NULL dereference in get_queue_ids()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53331", " - slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53146", " - thunderbolt: Limit XDomain response copy to actual frame size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53147", " - thunderbolt: Validate XDomain request packet size before type cast", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53148", " - thunderbolt: Clamp XDomain response data copy to allocation size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53149", " - thunderbolt: Bound root directory content to block size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53150", " - thunderbolt: Reject zero-length property entries in validator", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52929", " - sctp: stream: fully roll back denied add-stream state", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52917", " - sctp: diag: reject stale associations in dump_one path", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53154", " - mm/hugetlb: restore reservation on error in hugetlb folio copy paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53336", " - nvmem: layouts: onie-tlv: fix hang on unknown types", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53337", " - net: bonding: fix NULL pointer dereference in bond_do_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53158", " - misc: fastrpc: Fix NULL pointer dereference in rpmsg callback", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53159", " - misc: fastrpc: fix DMA address corruption due to find_vma misuse", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53160", " - misc: fastrpc: fix use-after-free race in fastrpc_map_create", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53161", " - misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52930", " - ipc/shm: serialize orphan cleanup with shm_nattch updates", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53339", " - i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53168", " - fuse: reject fuse_notify() pagecache ops on directories", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53177", " - bnxt_en: Fix NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53181", " - vsock/vmci: fix sk_ack_backlog leak on failed handshake", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53182", " - wifi: nl80211: reject oversized EMA RNR lists", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53183", " - mptcp: allow subflow rcv wnd to shrink", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63867", " - mptcp: close TOCTOU race while computing rcv_wnd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53343", " - ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53184", " - udp: clear skb->dev before running a sockmap verdict", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53185", " - zram: fix use-after-free in zram_bvec_write_partial()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53190", " - drm/virtio: fix dma_fence refcount leak on error in", " virtio_gpu_dma_fence_wait()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53194", " - USB: serial: kl5kusb105: fix bulk-out buffer overflow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53195", " - USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53196", " - USB: serial: io_ti: fix heap overflow in get_manuf_info()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52935", " - xfrm: espintcp: do not reuse an in-progress partial send", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53198", " - ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53356", " - drm/i915/gem: Fix phys BO pread/pwrite with offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53345", " - KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53208", " - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53209", " - Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53213", " - drm/vc4: fix krealloc() memory leak", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53347", " - drm/virtio: Fix driver removal with disabled KMS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43116", " - netfilter: ctnetlink: ensure safe access to master conntrack", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53214", " - ipv6: Fix a potential NPD in cleanup_prefix_route()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53217", " - net: mvpp2: sync RX data at the hardware packet offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53218", " - netfilter: nft_exthdr: fix register tracking for F_PRESENT flag", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52942", " - netfilter: nf_log: validate MAC header was set before dumping it", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53219", " - netfilter: x_tables: avoid leaking percpu counter pointers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53349", " - netfilter: nf_conntrack: destroy stale expectfn expectations on", " unregister", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52939", " - net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic", " completion", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53223", " - net: guard timestamp cmsgs to real error queue skbs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53227", " - net: openvswitch: fix possible kfree_skb of ERR_PTR", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53230", " - net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52947", " - net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53232", " - net: phy: clean the sfp upstream if phy probing fails", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53236", " - tcp: restrict SO_ATTACH_FILTER to priv users", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53350", " - ASoC: wm_adsp: Fix NULL dereference when removing firmware controls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53237", " - gpio: mvebu: fix NULL pointer dereference in suspend/resume", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53238", " - netlabel: validate unlabeled address and mask attribute lengths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53239", " - xfrm: policy: fix use-after-free on inexact bin in", " xfrm_policy_bysel_ctx()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46320", " - tap: free page on error paths in tap_get_user_xdp()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53242", " - ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked", " streams", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53352", " - signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53245", " - net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63870", " - ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53249", " - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53252", " - Bluetooth: fix memory leak in error path of hci_alloc_dev()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53253", " - Bluetooth: bnep: reject short frames before parsing", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53254", " - Bluetooth: RFCOMM: validate skb length in MCC handlers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53255", " - Bluetooth: MGMT: validate advertising TLV before type checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53256", " - Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63868", " - net: garp: fix unsigned integer underflow in garp_pdu_parse_attr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53353", " - hsr: Remove WARN_ONCE() in hsr_addr_is_self().", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53263", " - 6lowpan: fix off-by-one in multicast context address compression", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53264", " - net/sched: act_api: use RCU with deferred freeing for action lifecycle", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53265", " - dm cache policy smq: check allocation under invalidate lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53266", " - netfilter: bridge: make ebt_snat ARP rewrite writable", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53267", " - netfilter: nft_ct: bail out on template ct in get eval", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53268", " - netfilter: conntrack_irc: fix possible out-of-bounds read", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53269", " - netfilter: synproxy: add mutex to guard hook reference counting", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53270", " - ipvs: clear the svc scheduler ptr early on edit", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53273", " - tee: optee: prevent use-after-free when the client exits before the", " supplicant", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53274", " - net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53275", " - ipv6: mcast: Fix use-after-free when processing MLD queries", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52948", " - i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63898", " - USB: serial: mct_u232: fix memory corruption with small endpoint", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52910", " - bpf: Free reuseport cBPF prog after RCU grace period.", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43311", " - soc/tegra: pmc: Fix unsafe generic_handle_irq() call", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43240", " - x86/kexec: add a sanity check on previous kernel's ima kexec buffer", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-23346", " - arm64: io: Extract user memory type in ioremap_prot()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52944", " - ksmbd: fix FSCTL permission bypass by adding a permission check for", " FSCTL_SET_SPARSE", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64006", " - netfilter: nf_tables: fix dst corruption in same register operation", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547)", " - Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size", " - drm/v3d: Fix use-after-free of CPU job query arrays on error path", " - drm/v3d: Release indirect CSD GEM reference on CPU job free", " - xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit", " - net/sched: sch_sfb: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - bcache: fix uninitialized closure object", " - nfc: llcp: Fix use-after-free in llcp_sock_release()", " - nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()", " - xfrm: Check for underflow in xfrm_state_mtu", " - nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems", " - kunit: fix use-after-free in debugfs when using kunit.filter", " - netfilter: xt_cpu: prefer raw_smp_processor_id", " - vsock: keep poll shutdown state consistent", " - net: netlink: fix sending unassigned nsid after assigned one", " - net: netlink: don't set nsid on local notifications", " - net/smc: Do not re-initialize smc hashtables", " - net/iucv: fix locking in .getsockopt", " - scsi: core: Run queues for all non-SDEV_DEL devices from", " scsi_run_host_queues", " - ipv4: free net->ipv4.sysctl_local_reserved_ports after", " unregister_net_sysctl_table()", " - ALSA: pcm: oss: Fix setup list UAF on proc write error", " - ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors", " - gpio: mxc: fix irq_high handling", " - ethtool: rss: fix hkey leak when indir_size is 0", " - ASoC: codecs: simple-mux: Fix enum control bounds check", " - Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()", " - bonding: refuse to enslave CAN devices", " - ethtool: eeprom: add missing ethnl_ops_begin() / _complete() during", " fallback", " - ethtool: eeprom: add more safeties to EEPROM Netlink fallback", " - net/sched: Revert \"net/sched: Restrict conditions for adding duplicating", " netems to qdisc tree\"", " - net/handshake: Use spin_lock_bh for hn_lock", " - nvme-tcp: store negative errno in queue->tls_err", " - net/handshake: Pass negative errno through handshake_complete()", " - Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success", " - Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp", " - Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close", " - gpio: rockchip: convert bank->clk to devm_clk_get_enabled()", " - net: mana: Add NULL guards in teardown path to prevent panic on attach", " failure", " - sctp: fix race between sctp_wait_for_connect and peeloff", " - ipv6: fix possible infinite loop in rt6_fill_node()", " - ipv6: fix possible infinite loop in fib6_select_path()", " - net: skbuff: fix pskb_carve leaking zcopy pages", " - perf: Fix dangling cgroup pointer in cpuctx", " - batman-adv: tvlv: abort OGM send on tvlv append failure", " - batman-adv: tt: reject oversized local TVLV buffers", " - batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface", " - batman-adv: iv: recover OGM scheduling after forward packet error", " - batman-adv: tp_meter: avoid role confusion in tp_list", " - batman-adv: tp_meter: directly shut down timer on cleanup", " - batman-adv: tt: avoid empty VLAN responses", " - batman-adv: bla: avoid double decrement of bla.num_requests", " - media: rc: fix race between unregister and urb/irq callbacks", " - media: rc: ttusbir: fix inverted error logic", " - inet: frags: add inet_frag_queue_flush()", " - HID: core: Add printk_ratelimited variants to hid_warn() etc", " - drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register", " - drm/i915/psr: Read Intel DPCD workaround register", " - drm/dp: Add eDP 1.5 bit definition", " - drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used", " - phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X", " - batman-adv: tt: prevent TVLV entry number overflow", " - iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer", " - usb: typec: ucsi: ccg: reject firmware images without a ':' record", " header", " - usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload", " VDO", " - usb: typec: altmodes/displayport: validate count before reading Status", " Update VDO", " - usb: typec: wcove: don't write past struct pd_message in", " wcove_read_rx_buffer()", " - usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT", " - usb: typec: ucsi: validate connector number in ucsi_connector_change()", " - USB: serial: safe_serial: fix memory corruption with small endpoint", " - media: rc: igorplugusb: fix control request setup packet", " - Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free()", " - HID: quirks: Add ALWAYS_POLL quirk for SIGMACHIP USB mouse", " - Bluetooth: btusb: Allow firmware re-download when version matches", " - hpfs: fix a crash if hpfs_map_dnode_bitmap fails", " - auxdisplay: line-display: fix OOB read on zero-length message_store()", " - Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn", " - Bluetooth: HIDP: fix missing length checks in hidp_input_report()", " - Bluetooth: ISO: fix UAF in iso_recv_frame", " - Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock", " - Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync", " - Input: xpad - fix out-of-bounds access for Share button", " - parport: Fix race between port and client registration", " - USB: cdc-acm: Fix bit overlap and move quirk definitions to header", " - KVM: arm64: PMU: Preserve AArch32 counter low bits", " - KVM: SVM: Flush the current TLB when transitioning from xAVIC => x2AVIC", " - iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux", " - iio: adc: npcm: fix unbalanced clk_disable_unprepare()", " - iio: dac: max5821: fix return value check in powerdown sync", " - iio: dac: ad5686: fix input raw value check", " - iio: dac: ad5686: acquire lock when doing powerdown control", " - iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw", " - iio: gyro: itg3200: fix i2c read into the wrong stack location", " - iio: gyro: adis16260: fix division by zero in write_raw", " - iio: ssp_sensors: cancel delayed work_refresh on remove", " - iio: temperature: tsys01: fix broken PROM checksum validation", " - iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL", " - iio: light: cm3323: fix reg_conf not being initialized correctly", " - iio: buffer: hw-consumer: fix use-after-free in error path", " - USB: serial: omninet: fix memory corruption with small endpoint", " - usb: cdns3: gadget: fix request skipping after clearing halt", " - usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy", " acquisition failure", " - usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently", " leaks the runtime PM usage counter across bind/unbind cycles", " - usb: dwc2: Fix use after free in debug code", " - Input: elan_i2c - validate firmware size before use", " - wireguard: send: append trailer after expanding head", " - bpf: sockmap: fix tail fragment offset in bpf_msg_push_data", " - macsec: fix replay protection at XPN lower-PN wrap", " - ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params", " - ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().", " - ipv6: validate extension header length before copying to cmsg", " - xfrm: input: hold netns during deferred transport reinjection", " - ip6: vti: Use ip6_tnl.net in vti6_changelink().", " - HID: wacom: Fix OOB write in wacom_hid_set_device_mode()", " - iommu, debugobjects: avoid gcc-16.1 section mismatch warnings", " - nfc: hci: fix out-of-bounds read in HCP header parsing", " - xfrm: route MIGRATE notifications to caller's netns", " - xfrm: ah: use skb_to_full_sk in async output callbacks", " - ALSA: scarlett2: Fix 2i2 Gen 4 direct monitor gain on firmware 2417", " - netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without", " direction check", " - ASoC: qcom: q6asm-dai: close stream only when running", " - ASoC: qcom: q6asm-dai: do not set stream state in event and trigger", " callbacks", " - Input: xpad - add \"Nova 2 Lite\" from GameSir", " - Input: xpad - add support for ASUS ROG RAIKIRI II", " - ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops", " - Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem", " - Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490", " - comedi: comedi_test: fix check for valid scan_begin_src in", " waveform_ai_cmdtest()", " - comedi: comedi_test: Fix limiting of convert_arg in", " waveform_ai_cmdtest()", " - counter: Fix refcount leak in counter_alloc() error path", " - tty: serial: pch_uart: add check for dma_alloc_coherent()", " - usb: chipidea: core: convert ci_role_switch to local variable", " - usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval", " - USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub", " controllers", " - usb: storage: Add quirks for PNY Elite Portable SSD", " - usbip: vudc: Fix use after free bug in vudc_remove due to race condition", " - usb: usbtmc: check URB actual_length for interrupt-IN notifications", " - usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize", " - USB: serial: option: add MeiG SRM813Q", " - USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL", " - USB: serial: belkin_sa: validate interrupt status length", " - USB: serial: cypress_m8: validate interrupt packet headers", " - USB: serial: keyspan: fix missing indat transfer sanity check", " - USB: serial: mxuport: fix memory corruption with small endpoint", " - USB: serial: mct_u232: fix missing interrupt-in transfer sanity check", " - usb: gadget: uvc: hold opts->lock across XU walks in uvc_function_bind", " - usb: gadget: net2280: Fix double free in probe error path", " - usb: gadget: f_hid: fix device reference leak in hidg_alloc()", " - usb: gadget: composite: fix integer underflow in WebUSB GET_URL handling", " - usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports", " - usb: gadget: f_fs: copy only received bytes on short ep0 read", " - thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()", " - thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow", " - scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker", " - scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32", " - drm/hyperv: validate resolution_count and fix WIN8 fallback", " - drm/hyperv: validate VMBus packet size in receive callback", " - drm/i915: Fix potential UAF in TTM object purge", " - drm/amd/pm/si: Disregard vblank time when no displays are connected", " - serial: altera_jtaguart: handle uart_add_one_port() failures", " - serial: qcom-geni: fix UART_RX_PAR_EN bit position", " - serial: sh-sci: fix memory region release in error path", " - serial: zs: Fix swapped RI/DSR modem line transition counting", " - serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma", " - drm/amdkfd: fix NULL pointer bug in svm_range_set_attr", " - drm/amdkfd: fix a vulnerability of integer overflow in kfd debugger", " - drm/amdkfd: Check for pdd drm file first in CRIU restore path", " - serial: dz: Fix bootconsole message clobbering at chip reset", " - serial: dz: Fix bootconsole handover lockup", " - serial: dz: Convert to use a platform device", " - serial: zs: Fix bootconsole handover lockup", " - serial: zs: Switch to using channel reset", " - serial: zs: Convert to use a platform device", " - USB: serial: cypress_m8: fix memory corruption with small endpoint", " - USB: serial: digi_acceleport: fix memory corruption with small endpoints", " - xhci: tegra: Fix ghost USB device on dual-role port unplug", " - iommu: Skip PASID validation for devices without PASID capability", " - x86/boot: Disable stack protector for early boot code", " - rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg", " - rxrpc: Fix RESPONSE packet verification to extract skb to a linear", " buffer", " - serdev: Provide a bustype shutdown function", " - Bluetooth: hci_qca: Migrate to serdev specific shutdown function", " - Bluetooth: hci_qca: Convert timeout from jiffies to ms", " - ALSA: scarlett2: Return ENOSPC for out-of-bounds flash writes", " - ALSA: scarlett2: Allow flash writes ending at segment boundary", " - mm/memory: fix spurious warning when unmapping device-private/exclusive", " pages", " - platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery", " - net: hsr: defer node table free until after RCU readers", " - mptcp: pm: fix ADD_ADDR timer infinite retry on option space", " insufficient", " - ice: fix VF queue configuration with low MTU values", " - mptcp: cleanup fallback dummy mapping generation", " - mptcp: reset rcv wnd on disconnect", " - arm64: tlb: Flush walk cache when unsharing PMD tables", " - octeontx2-pf: avoid double free of pool->stack on AQ init failure", " - mptcp: introduce the mptcp_init_skb helper", " - mptcp: handle first subflow closing consistently", " - mptcp: do not drop partial packets", " - mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()", " - iio: chemical: scd30: Use guard(mutex) to allow early returns", " - iio: chemical: scd30: fix division by zero in write_raw", " - iio: dac: ad5686: fix ref bit initialization for single-channel parts", " - ALSA: firewire-motu: Protect register DSP event queue positions", " - usb: dwc3: xilinx: fix error handling in zynqmp init error paths", " - usb: musb: omap2430: Fix use-after-free in omap2430_probe()", " - usb: typec: ucsi: Check if power role change actually happened before", " handling", " - thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()", " - usb: typec: ucsi: Don't update power_supply on power role change if not", " connected", " - hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with", " pmbus_lock", " - hwmon: (pmbus/adm1266) serialize NVMEM blackbox read with pmbus_lock", " - hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock", " - mm: perform all memfd seal checks in a single place", " - mm/memfd: fix spelling and grammatical issues", " - memfd: deny writeable mappings when implying SEAL_WRITE", " - usb: core: Fix SuperSpeed root hub wMaxPacketSize", " - Upstream stable to v6.12.93", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43331", " - x86/kexec: Disable KCOV instrumentation after load_segments()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52943", " - net: skbuff: fix missing zerocopy reference in pskb_carve helpers", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53358", " - Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52923", " - ipc: limit next_id allocation to the valid ID range", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2025-68768", " - inet: frags: flush pending skbs in fqdir_pre_exit()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43303", " - mm/page_alloc: clear page->private in free_pages_prepare()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52934", " - batman-adv: tvlv: reject oversized TVLV packets", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52913", " - batman-adv: v: stop OGMv2 on disabled interface", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46322", " - tun: free page on build_skb failure in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46321", " - tun: free page on short-frame rejection in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52927", " - netfilter: ebtables: fix OOB read in compat_mtw_from_user", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43219", " - net: cpsw_new: Fix potential unregister of netdev that has not been", " registered yet", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-45930", " - net: mctp: ensure our nlmsg responses are initialised", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53080", " - net/sched: cls_fw: fix NULL dereference of \"old\" filters before change()", "", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Enable CONFIG_ARM64_ERRATUM_4118414", "", " * CVE-2025-10263", " - arm64: cputype: Add C1-Ultra definitions", " - arm64: cputype: Add C1-Premium definitions", "", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", "", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", "", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", "", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", "", " * CVE-2026-63886", " - scsi: target: iscsi: Validate CHAP_R length before base64 decode", "", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", "", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", "", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", "", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", "", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", "", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", "", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", "", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", "", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", "", " * CVE-2026-64000", " - net: hsr: fix potential OOB access in supervision frame handling", "", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", "", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", "", " * CVE-2026-53131", " - netfilter: require Ethernet MAC header before using eth_hdr()", "" ], "package": "linux", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:47:58 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-tools-common", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-147.147 -proposed tracker (LP: #2168142)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026)", " - platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug", " - selftests/bpf: Add tests for ld_{abs,ind} failure path in subprogs", " - drm/virtio: fix deadlock in display_info_cb by removing hotplug from", " dequeue worker", " - mtd: mtdswap: remove debugfs stats file on teardown", " - seqlock: Cure some more scoped_seqlock() optimization fails", " - seqlock: Allow KASAN to fail optimizing", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/umem: Add support for creating pinned DMABUF umem with a given dma", " device", " - RDMA/umem: Introduce an option to revoke DMABUF umem", " - RDMA/umem: Add ib_umem_dmabuf_get_pinned_and_lock helper", " - RDMA/umem: Move umem dmabuf revoke logic into helper function", " - RDMA/umem: Add pinned revocable dmabuf import interface", " - RDMA/umem: Add helpers for umem dmabuf revoke lock", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - selftests/alsa: Fix memory leak in find_controls error path", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: cs42l43: Correct report for forced microphone jack", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - sched/vtime: Get rid of generic vtime_task_switch() implementation", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - can: j1939: fix lockless local-destination check", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - crypto: rsa-pkcs1pad: Don't WARN on an empty digest", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - wifi: ath11k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - wifi: ath12k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - ASoC: cs35l56: Don't use devres to unregister component", " - ASoC: cs35l56: Fix potential probe() deadlock", " - ASoC: cs35l56: Use complete_all() to signal init_completion", " - wifi: iwlwifi: mvm: validate SAR GEO response payload size", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - hwmon: (asus-ec-sensors) fix looping over banks while reading from EC", " - hwmon: (asus-ec-sensors) fix EC read intervals", " - hwmon: (asus-ec-sensors) add missed handle for ENOMEM", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - pds_core: yield the CPU while waiting for the adminq to drain", " - pds_core: order completion reads after the ownership check", " - pds_core: check for workqueue allocation failure", " - tls: device: push pending open record on splice EOF", " - selftest: af_unix: Add Kconfig file.", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - amt: make the head writable before rewriting the L2 header", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: dpaa: fix mode setting", " - iomap: correct the range of a partial dirty clear", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - net: stmmac: enable the MAC on link up for all supported speeds", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - ppp: use IFF_NO_QUEUE in virtual interfaces", " - ppp: convert to percpu netstats", " - ppp: enable TX scatter-gather", " - ppp: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: fix LAG recipe to profile association", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't", " at 0 (v2)", " - drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nxp: imx8-isi: Clean up already-initialized pipes on probe", " failure", " - media: nxp: imx8-isi: Fix missing v4l2_subdev_cleanup() in pipe init", " error path", " - media: nxp: imx8-isi: Fix scale factor calculation for hardware rounding", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vivid: add vivid_update_reduced_fps()", " - media: vpif_capture: fix OF node reference imbalance", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - LoongArch: Fix oops during single-step debugging", " - x86/boot/compressed: Disable jump tables", " - serial: sc16is7xx: implement gpio get_direction() callback", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - ice: use READ_ONCE() to access cached PHC time", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amd/display: Fix dcn32 DTB DTO update breaking live pixel rate", " sources", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - net: pcs: xpcs: fix SGMII state reading", " - bpf: drop bpf_lsm_getselfattr from hook list", " - udmabuf: Do not create malformed scatterlists", " - i2c: davinci: Unregister cpufreq notifier on probe failure", " - VFS/audit: introduce kern_path_parent() for audit", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - rxrpc: Pull out certain app callback funcs into an ops table", " - fbcon: Rename struct fbcon_ops to struct fbcon_par", " - fbcon: Use correct type for vc_resize() return value", " - rxrpc: Don't need barrier for ->tx_bottom and ->acks_hard_ack", " - rxrpc: Use irq-disabling spinlocks between app and I/O thread", " - rxrpc: Fix notification vs call-release vs recvmsg", " - rxrpc: Fix socket notification race", " - vduse: Use fixed 4KB bounce pages for non-4KB page size", " - vduse: remove unused vaddr parameter of vduse_domain_free_coherent", " - vduse: take out allocations from vduse_dev_alloc_coherent", " - octeontx2: Annotate mmio regions as __iomem", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - fbdev/efifb: Replace references to global screen_info by local pointer", " - ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable()", " - ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe()", " - ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb", " - ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - netfilter: nft_set_pipapo: use GFP_KERNEL for insertions", " - netfilter: nft_set_pipapo: move prove_locking helper around", " - netfilter: nft_set_pipapo: make pipapo_clone helper return NULL", " - netfilter: nft_set_pipapo: prepare walk function for on-demand clone", " - netfilter: nft_set_pipapo: merge deactivate helper into caller", " - netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone", " - netfilter: nft_set_pipapo: move cloning of match info to insert/removal", " path", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_tables: Remove unused nft_reduce_is_readonly()", " - netfilter: nf_tables: remove register tracking infrastructure", " - NFSD: pass nfsd_file to nfsd_iter_read()", " - sunrpc: allocate a separate bvec array for socket sends", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - dma: dw-edma: Fix build warning in dw_edma_pcie_probe()", " - dmaengine: dw-edma: Fix confusing cleanup.h syntax", " - platform/x86: dell-smbios: Move request functions for reuse", " - i2c: imx: separate atomic, dma and non-dma use case", " - nfs: remove dead code for the old swap over NFS implementation", " - ovl: use linked upper dentry in copy-up tmpfile", " - bootconfig: do not put quotes on cmdline items unless necessary", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - rxrpc: Disable IRQ, not BH, to take the lock for ->attend_link", " - netfilter: nft_quota: use atomic64_xchg for reset", " - soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE", " - wifi: cfg80211: pass net_device to .set_monitor_channel", " - wifi: cfg80211: define and use wiphy guard", " - wifi: cfg80211: derive S1G beacon TSF from S1G fields", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - smb: move some duplicate definitions to common/cifsglob.h", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - wifi: mt76: mt7925: extend mt7925_mcu_bss_he_tlv for per-link BSS", " - ovl: fix trusted xattr escape prefix matching", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - dpll: add clock quality level attribute and op", " - net/mlx5: DPLL, Add clock quality level op implementation", " - net/mlx5: Remove newline at the end of a netlink error message", " - net/mlx5: Refactor EEPROM query error handling to return status", " separately", " - octeontx2-pf: tc: fix egress ratelimiting", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm/displayid: move drm_displayid.h to drm_displayd_internal.h", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - ALSA: timer: drain a slave's callback before its master detaches it", " - ALSA: timer: don't re-enter an instance callback that is still running", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - sysctl: treewide: constify ctl_table_header::ctl_table_arg", " - ceph: fix refcount leak in ceph_readdir()", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - net: move skb_gro_receive_list from udp to core", " - net: add pskb_may_pull() to skb_gro_receive_list()", " - vsock/virtio: collapse receive queue under memory pressure", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - xfs: add an explicit owner field to xfs_da_args", " - xfs: factor out xfs_attr3_leaf_init", " - xfs: don't replace the wrong part of the cow fork", " - rxrpc: Fix CPU time starvation in I/O thread", " - ASoC: mediatek: mt8183-afe-pcm: Shorten memif_data table using macros", " - ASoC: mediatek: mt8183-afe-pcm: Support >32 bit DMA addresses", " - tcp: Decrement tcp_md5_needed static branch", " - nvmet: Introduce nvmet_req_transfer_len()", " - block: add helper add_disk_final()", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections", " - Bluetooth: hci_core: Fix not accounting for BIS/CIS/PA links separately", " - afs: Improve server refcount/active count tracing", " - afs: Make afs_lookup_cell() take a trace note", " - afs: Drop the net parameter from afs_unuse_cell()", " - rxrpc: Allow the app to store private data on peer structs", " - afs: Use the per-peer app data provided by rxrpc", " - afs: Fix afs_server ref accounting", " - afs: Simplify cell record handling", " - afs: Fix dynamic lookup to fail on cell lookup failure", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - lib/string_choices: Add str_plural() helper", " - USB: gadget: Use str_enable_disable-like helpers", " - usb: musb: omap2430: clean up probe error handling", " - net/mlx5e: Fix NULL pointer dereference in ioctl module EEPROM query", " - rxrpc: Fix locking issues with the peer record hash", " - wifi: nl80211: fix nl80211_start_radar_detection return value", " - afs: Set vllist to NULL if addr parsing fails", " - dpll: fix clock quality level reporting", " - afs: Fix delayed allocation of a cell's anonymous key", " - afs: handle CB.InitCallBackState3 requests without a server record", " - Bluetooth: hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK", " - Bluetooth: hci_conn: Fix not cleaning up Broadcaster/Broadcast Source", " - Bluetooth: hci_conn: Remove redundant memset after kzalloc", " - Bluetooth: hci_conn: Fix not cleaning up PA_LINK connections", " - Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()", " - afs: Fix uninit var in afs_alloc_anon_key()", " - Upstream stable to v6.6.148, v6.12.101", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72168", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72213", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72244", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53078", " - bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2025-40098", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_get_acpi_mute_state()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68372", " - usb: core: port: Deattach Type-C connector on component unbind", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72175", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45901", " - netfilter: nf_tables: revert commit_mutex usage in reset path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45897", " - netfilter: nft_counter: serialize reset with spinlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72015", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72017", " - net: macb: drop in-flight Tx SKBs on close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72030", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72023", " - octeontx2-pf: fix SQB pointer leak on init failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72040", " - ipmi: fix refcount leak in i_ipmi_request()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72045", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72062", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72051", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72070", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72142", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72147", " - dmaengine: dw-edma-pcie: Reject devices without driver data", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72254", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72253", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72260", " - ASoC: mediatek: mt8192: Check runtime resume during probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72305", " - VDUSE: avoid leaking information to userspace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64205", " - i2c: i801: fix hardware state machine corruption in error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64280", " - fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72146", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72124", " - can: isotp: serialize TX state transitions under so->rx_lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72125", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72115", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72117", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72116", " - can: bcm: fix stale rx/tx ops after device removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72113", " - can: bcm: add missing device refcount for CAN filter removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72114", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72119", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72118", " - can: bcm: fix CAN frame rx/tx statistics", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72121", " - can: bcm: add locking when updating filter and timer values", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53090", " - bpf: Fix ld_{abs,ind} failure path analysis in subprogs", "", " * test_vxlan_vnifiltering.sh from ubuntu_kselftests_net failed on linux-", " oem-6.8 (with ipv6 default rdst) (LP: #2071590)", " - selftests: net: use slowwait to make sure IPv6 setup finished", "", " * ubuntu_bpf failed to build in noble (error: redefinition of", " 'stack_load_preserves_const_precision') (LP: #2160493)", " - SAUCE: Revert \"selftests/bpf: validate fake register spill/fill", " precision backtracking logic\"", "", " * CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", "", " * Backport: \"mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios\"", " (LP: #2162917)", " - mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios", "", " * qrtr: ns: node limit of 64 breaks QRTR routing on large multi-node", " deployments (LP: #2165140)", " - net: qrtr: ns: Raise node count limit to 512", "", " * [UBUNTU 24.04] kernel: CPU hotplug unsupported by CPUMF (LP: #2165732)", " - s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks", "", " * CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", "", " * CVE-2025-38563", " - perf/core: Prevent VMA split of buffer mappings", "", " * CVE-2025-38565", " - perf/core: Exit early on perf_mmap() fail", "", " * CVE-2025-38187", " - drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()", "", " * CVE-2025-38069", " - PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops", "", " * CVE-2025-40014", " - objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()", "", " * CVE-2025-21985", " - drm/amd/display: Fix out-of-bound accesses", "", " * CVE-2024-56552", " - drm/xe/guc_submit: fix race around suspend_pending", "", " * CVE-2025-21687", " - vfio/platform: check the bounds of read/write syscalls", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237)", " - ext4: fix fd leak in EXT4_IOC_MOVE_EXT cross-sb validation", " - mm: refactor mm_access() to not return NULL", " - Upstream stable to v6.6.146, v6.12.98, v6.6.147, v6.12.99, v6.12.100", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237) //", " CVE-2026-64560", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995)", " - bpf, arm64: Reject out-of-range B.cond targets", " - nfsd: release layout stid on setlease failure", " - Bluetooth: btmtk: apply the common btmtk_fw_get_filename", " - Bluetooth: btmtk: Fix failed to send func ctrl for MediaTek devices.", " - Bluetooth: btmtk: Fix wait_on_bit_timeout interruption during shutdown", " - userfaultfd: gate must_wait writability check on pte_present()", " - perf: Fix dangling cgroup pointer in cpuctx backport", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error", " - device property: initialize the remaining fields of fwnode_handle in", " fwnode_init()", " - f2fs: validate orphan inode entry count", " - f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode", " - f2fs: fix potential deadlock in f2fs_balance_fs()", " - f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()", " - f2fs: fix listxattr handling of corrupted xattr entries", " - block: Avoid mounting the bdev pseudo-filesystem in userspace", " - i2c: core: fix irq domain leak on adapter registration failure", " - i2c: core: fix hang on adapter registration failure", " - i2c: core: fix NULL-deref on adapter registration failure", " - i2c: core: fix adapter debugfs creation", " - fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()", " - NFSv4/flexfiles: reject zero filehandle version count", " - locking/rtmutex: Make sure we wake anything on the wake_q when we", " release the lock->wait_lock", " - bonding: fix xfrm offload feature setup on active-backup mode", " - mm/vmscan: flush deferred TLB before freeing large folios", " - perf trace beauty fcntl: Fix build with older kernel headers", " - ACPI: CPPC: Suppress UBSAN warning caused by field misuse", " - ACPI: NFIT: core: Fix possible NULL pointer dereference", " - perf/core: Detach event groups during remove_on_exec", " - arm64: sysreg: Add layout for ID_AA64MMFR4_EL1", " - virtio_net: Support dynamic rss indirection table size", " - LoongArch: Add PIO for early access before ACPI PCI root register", " - usb: gadget: function: rndis: add length check to response query", " - usb: gadget: function: rndis: add length check for header", " - iio: accel: bmc150: clamp the device-reported FIFO frame count", " - iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error", " - iio: adc: lpc32xx: Initialize completion before requesting IRQ", " - iio: adc: ti-ads124s08: Return reset GPIO lookup errors", " - iio: chemical: scd30: Cleanup initializations and fix sign-extension bug", " - iio: event: Fix event FIFO reset race", " - iio: gyro: bmg160: bail out when bandwidth/filter is not in table", " - iio: gyro: bmg160: wait full startup time after mode change at probe", " - iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ", " - iio: imu: st_lsm6dsx: deselect shub page before reading whoami", " - iio: light: al3010: fix incorrect scale for the highest gain range", " - iio: light: gp2ap002: fix runtime PM leak on read error", " - iio: light: opt3001: fix missing state reset on timeout", " - iio: light: tsl2591: return actual error from probe IRQ failure", " - iio: light: veml6030: fix channel type when pushing events", " - iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call", " - iio: temperature: ltc2983: Fix reinit_completion() called after", " conversion start", " - ALSA: virtio: Add missing 384 kHz PCM rate mapping", " - ALSA: ymfpci: check snd_ctl_new1() return value", " - ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input", " parser", " - ALSA: cmipci: check snd_ctl_new1() return value", " - ALSA: es1938: check snd_ctl_new1() return value", " - ALSA: firewire: isight: bound the sample count to the packet payload", " - ALSA: gus: check snd_ctl_new1() return value", " - ALSA: ice1712: check snd_ctl_new1() return value", " - ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()", " - ALSA: usb-audio: avoid kobject path lookup in DualSense match", " - ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()", " - ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch", " put callbacks", " - ALSA: usb-audio: Update Babyface Pro control caches only after", " successful writes", " - ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful", " writes", " - vfio/pci: Use a private flag to prevent power state change with VFs", " - vfio/pci: Latch disable_idle_d3 per device", " - vfio/pci: Release the VGA arbiter client on register_device() failure", " - vfio/pci: Fix racy bitfields and tighten struct layout", " - vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc", " - Bluetooth: btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB", " - Bluetooth: btusb: fix use-after-free on registration failure", " - Bluetooth: btusb: fix use-after-free on marvell probe failure", " - Bluetooth: btusb: fix wakeup source leak on probe failure", " - binder: fix UAF in binder_thread_release()", " - binder: fix UAF in binder_free_transaction()", " - usb: xhci: Fix sleep in atomic context in xhci_free_streams()", " - PCI: altera: Do not dispose parent IRQ mapping", " - mm/damon/ops-common: handle extreme intervals in damon_hot_score()", " - netfilter: ipset: fix race between dump and ip_set_list resize", " - virtio-mmio: fix device release warning on module unload", " - hwrng: virtio: clamp device-reported used.len at copy_data()", " - USB: chaoskey: Fix slab-use-after-free in chaoskey_release()", " - usb: dwc3: run gadget disconnect from sleepable suspend context", " - 6lowpan: fix NHC entry use-after-free on error path", " - tipc: fix out-of-bounds read in broadcast Gap ACK blocks", " - staging: vme_user: bound slave read/write to the kern_buf size", " - smb: client: restrict implied bcc[0] exemption to responses without data", " area", " - staging: vme_user: fix location monitor leak in fake bridge", " - staging: vme_user: fix location monitor leak in tsi148 bridge", " - media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe", " - staging: media: atomisp: reduce load_primary_binaries() stack usage", " - staging: rtl8723bs: fix heap buffer overflow in", " rtw_cfg80211_set_wpa_ie()", " - staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()", " - staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop", " - staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop", " - staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and", " join_cmd_hdl()", " - staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop", " - staging: rtl8723bs: fix OOB write in HT_caps_handler()", " - crypto: amlogic - avoid double cleanup in meson_crypto_probe()", " - ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then", " SMB2_CANCEL", " - net: af_key: initialize alg_key_len for IPComp states", " - audit: Fix data races of skb_queue_len() readers on audit_queue", " - Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete", " - debugobjects: Plug race against a concurrent OOM disable", " - fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns", " - NTB: epf: Avoid calling pci_irq_vector() from hardirq context", " - io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item", " - ipv4: igmp: remove multicast group from hash table on device destruction", " - net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes", " - mfd: cros_ec: Delay dev_set_drvdata() until probe success", " - mm: shrinker: fix NULL pointer dereference in debugfs", " - netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump", " - f2fs: bound i_inline_xattr_size for non-inline-xattr inodes", " - drm/amd: Fix set but not used warnings", " - apparmor: advertise the tcp fast open fix is applied", " - nfsd: move name lookup out of nfsd4_list_rec_dir()", " - nfsd: change nfs4_client_to_reclaim() to allocate data", " - arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative", " - arm64: Fix early handling of FEAT_E2H0 not being implemented", " - KVM: arm64: Initialize HCR_EL2.E2H early", " - arm64: Revamp HCR_EL2.E2H RES1 detection", " - arm64: sysreg: Correct sign definitions for EIESB and DoubleLock", " - iio: adc: spear: Initialize completion before requesting IRQ", " - iio: imu: inv_icm42600: fix timestamp clock period by using lower value", " - ALSA: usb-audio: Roll back quirk control caches on write errors", " - usb: typec: tcpci_rt1711h: unregister TCPCI port with devres", " - gpio: eic-sprd: use raw_spinlock_t in the irq startup path", " - netfilter: ebtables: module names must be null-terminated", " - netfilter: ebtables: terminate table name before find_table_lock()", " - Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()", " - Bluetooth: bnep: pin L2CAP connection during netdev registration", " - Bluetooth: btnxpuart: Fix out-of-bounds firmware read in", " nxp_recv_fw_req_v3()", " - Bluetooth: fix UAF in bt_accept_dequeue()", " - Bluetooth: L2CAP: validate option length before reading conf opt value", " - fs/ntfs3: fsync files by syncing parent inodes", " - fs/ntfs3: zero-fill folios beyond i_valid in ntfs_read_folio()", " - fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()", " - coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer()", " - smb/client: Fix error code in smb2_aead_req_alloc()", " - ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE", " - ksmbd: add a permission check for FSCTL_SET_ZERO_DATA", " - ksmbd: serialize QUERY_DIRECTORY requests per file", " - ksmbd: require source read access for duplicate extents", " - ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock", " cancellation", " - ksmbd: add a WRITE_DAC/WRITE_OWNER check to SMB2 SET_INFO SECURITY", " - ksmbd: run set info with opener credentials", " - ksmbd: enforce FILE_READ_ATTRIBUTES on SMB_FIND_FILE_POSIX_INFORMATION", " - ksmbd: add per-handle permission check to FILE_LINK_INFORMATION", " - ksmbd: use opener credentials for delete-on-close", " - smb: client: fix query directory replay double-free", " - smb: client: fix query_info() replay double-free", " - smb: client: fix double-free in SMB2_ioctl() replay", " - smb: client: fix change notify replay double-free", " - smb: client: fix double-free in SMB2_flush() replay", " - smb: client: fix double-free in SMB2_open() replay", " - smb: client: fix double-free in SMB2_close() replay", " - smb: client: Fix next buffer leak in receive_encrypted_standard()", " - smb: client: use unaligned reads in parse_posix_ctxt()", " - smb: client: harden POSIX SID length parsing", " - smb: client: mask server-provided mode to 07777 in modefromsid", " - OPP: of: Fix potential memory leak in opp_parse_supplies()", " - firmware_loader: fix device reference leak in firmware_upload_register()", " - cpufreq: intel_pstate: Sync policy->cur during CPU offline", " - sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT", " - cpufreq: Fix hotplug-suspend race during reboot", " - cpufreq: pcc: fix use-after-free and double free in _OSC evaluation", " - posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path", " - clocksource/drivers/timer-tegra186: Fix support for multiple watchdog", " instances", " - X.509: Fix validation of ASN.1 certificate header", " - tools/mm/slabinfo: Fix trace disable logic inversion", " - tools/mm/slabinfo: fix total_objects attribute name", " - HID: wacom: stop hardware after post-start probe failures", " - HID: letsketch: fix UAF on inrange_timer at driver unbind", " - HID: lg-g15: cancel pending work on remove to fix a use-after-free", " - HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte", " reads", " - hfs/hfsplus: zero-initialize buffer in hfs_bnode_read", " - nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers", " - media: mtk-jpeg: cancel workqueue on release for supported platforms", " only", " - xfs: use null daddr for unset first bad log block", " - xfs: fix unreachable BIGTIME check in dquot flush validation", " - bpf: Reject fragmented frames in devmap", " - bpf: Restore sysctl new-value from 1 to 0", " - net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()", " - usb: cdc_acm: Add quirk for Uniden BC125AT scanner", " - usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()", " - USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub", " - usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()", " - usb: free iso schedules on failed submit", " - usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler", " - usb: gadget: udc: Fix use-after-free in gadget_match_driver", " - usb: gadget: f_printer: take kref only for successful open", " - USB: idmouse: fix use-after-free on disconnect race", " - USB: ldusb: fix use-after-free on disconnect race", " - USB: iowarrior: fix use-after-free on disconnect", " - USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD", " - USB: legousbtower: fix use-after-free on disconnect race", " - usb: sl811-hcd: disable controller wakeup on remove", " - USB: storage: include US_FL_NO_SAME in quirks mask", " - USB: misc: uss720: unregister parport on probe failure", " - usb: mtu3: unmap request DMA on queue failure", " - USB: serial: keyspan_pda: fix information leak", " - USB: serial: option: add Telit Cinterion FE990D50 compositions", " - USB: serial: digi_acceleport: fix broken rx after throttle", " - USB: serial: digi_acceleport: fix hard lockup on disconnect", " - USB: serial: digi_acceleport: fix write buffer corruption", " - USB: ulpi: fix memory leak on registration failure", " - USB: usb-storage: ene_ub6250: restore media-ready check", " - usbip: tools: support SuperSpeedPlus devices", " - usbip: vudc: fix NULL deref in vep_dequeue()", " - usb: typec: anx7411: use devm_pm_runtime_enable()", " - usb: typec: class: drop PD lookup reference", " - usb: typec: tcpm: Validate SVID index in svdm_consume_modes()", " - usb: typec: ucsi: Invert DisplayPort role assignment", " - usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt", " mode", " - usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove", " - usb: typec: ucsi: cancel pending work on system suspend", " - iio: temperature: ltc2983: Fix n_wires default bypassing rotation check", " - PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining", " - udf: validate free block extents against the partition length", " - udf: validate VAT header length against the VAT inode size", " - udf: validate sparing table length as an entry count, not a byte count", " - hwrng: jh7110 - fix refcount leak in starfive_trng_read()", " - dm-ioctl: report an error if a device has no table", " - nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace", " disks", " - btrfs: do not trim a device which is not writeable", " - partitions: aix: bound the pp_count scan to the ppe array", " - isofs: bound Rock Ridge symlink components to the SL record", " - crypto: af_alg - Remove zero-copy support from skcipher and aead", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps again", " - crypto: ecc - Fix carry overflow in vli multiplication", " - crypto: pcrypt - restore callback for non-parallel fallback", " - crypto: drbg - Fix returning success on failure in CTR_DRBG", " - crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels", " - crypto: drbg - Fix the fips_enabled priority boost", " - crypto: qat - validate RSA CRT component lengths", " - crypto: talitos - use dma_sync_single_for_cpu() before reading", " descriptor header", " - crypto: talitos - add chaining of arbitrary number of descriptor for the", " SEC1", " - crypto: talitos - move dma unmapping code in flush_channel() into a", " standalone dma_unmap_request() function", " - crypto: talitos - move dma mapping code in talitos_submit() into a", " standalone dma_map_request() function", " - crypto: talitos - move code in current_desc_hdr() into a standalone", " function", " - crypto: talitos/hash - prepare SEC1 descriptor chaining, remove", " additional descriptor", " - crypto: talitos/hash - use descriptor chaining for SEC1 instead of", " workqueue", " - crypto: talitos/hash - drop workqueue mechanism for SEC1", " - crypto: talitos/hash - rename first_desc/last_desc to", " first_request/last_request", " - crypto: talitos/hash - remove useless wrapper", " - crypto: talitos/hash - fix SEC2 64k - 1 ahash request limitation", " - arm64: fpsimd: Fix type mismatch in sme_{save,load}_state()", " - spi: fsl-lpspi: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - spi: fsl-lpspi: terminate the RX channel on TX prepare failure path", " - EDAC/i10nm: Don't fail probing if ADXL is missing", " - watchdog: apple: Add \"apple,t8103-wdt\" compatible", " - tracing: Prevent out-of-bounds read in glob matching", " - NFSv4: include MAY_WRITE in open permission mask for O_TRUNC", " - module: decompress: check return value of module_extend_max_pages()", " - exfat: bound uniname advance in exfat_find_dir_entry()", " - NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()", " - KVM: VMX: Refresh GUEST_PENDING_DBG_EXCEPTIONS.BS on all injected #DBs", " - KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest", " mode", " - udmabuf: fix DMA direction mismatch in release_udmabuf()", " - i2c: core: fix adapter deregistration race", " - i2c: mpc: Fix timeout calculations", " - i2c: stm32f7: truncate clock period instead of rounding it", " - Input: synaptics-rmi4 - unregister function handlers on physical driver", " registration failure", " - Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count", " - Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count", " - Input: elan_i2c - prevent division by zero and arithmetic underflow", " - Input: goodix - clamp the device-reported contact count", " - Input: iforce - bound the device-reported force-feedback effect index", " - Input: mms114 - fix touch indexing for MMS134S and MMS136", " - Input: touchwin - reset the packet index on every complete packet", " - Input: mms114 - reject an oversized device packet size", " - Input: maplemouse - fix NULL pointer dereference in open()", " - Input: mms114 - fix multi-touch slot corruption", " - Input: maple_keyb - set driver data before registering input device", " - Input: maplemouse - set driver data before registering input device", " - Input: maplecontrol - set driver data before registering input device", " - RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", " - fuse: fix device node leak in cuse_process_init_reply()", " - fuse: re-lock request before returning from fuse_ref_folio()", " - smb: client: reject overlapping data areas in SMB2 responses", " - xfs: fail recovery on a committed log item with no regions", " - xfs: resample the data fork mapping after cycling ILOCK", " - smb/server: do not require delete access for non-replacing links", " - sched/fair: Only update stats for allowed CPUs when looking for dst", " group", " - KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU", " - KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove CRYPTO_DEV_SUN4I_SS_PRNG", " - crypto: crypto4xx - Remove ahash-related code", " - bpf: Support for hardening against JIT spraying", " - x86/bugs: Enable IBPB flush on BPF JIT allocation", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix sequence number when no EOF", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - dt-bindings: power: imx93: Add MIPI PHY power domain", " - serial: msm: Disable DMA for kernel console UART", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: Fix further netns teardown to cancel the preallocation charger", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/amdgpu: fix integer overflow in amdgpu_gem_align_pitch()", " - drm/radeon: fix integer overflow in radeon_align_pitch()", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " - libbpf: Report error when a negative kprobe offset is specified", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg", " warning", " - wifi: cfg80211: fix grammar in MLO group key error message", " - arm64: tegra: Fix Tegra234 MGBE PTP clock", " - dt-bindings: pinctrl: nvidia,tegra234: Add missing required block", " - drm/amdkfd: Validate CRIU-restored IDs before idr_alloc", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sama5d4_wdt: Fix WDDIS detection on SAM9X60 and SAMA7G5", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - media: v4l2-common: Add YUV24 format info", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " - dlm: fix add msg handle in send_queue ordered", " - nilfs2: fix backing_dev_info reference leak", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - evm: terminate and bound the evm_xattrs read buffer", " - thermal: hwmon: Fix critical temperature attribute removal", " - clk: scpi: Unregister child clock providers on remove", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - spi: hisi-kunpeng: Use dev_err_probe() for host registration failure", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/srpt: fix integer overflow in immediate data length check", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - driver core: Use mod_delayed_work to prevent lost deferred probe work", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - bus: sunxi-rsb: Always check register address validity", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: seq: midi: Serialize output teardown with event_input", " - pinctrl: cs42l43: Fix polarity on debounce", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " - drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X", " client is registered", " - drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove", " - gpu: host1x: Allow entries in BO caches to be freed", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - gpu: host1x: Fix iommu_map_sgtable() return value check", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Harden parse_vma_segs() path parsing", " - libbpf: Fix UAF in strset__add_str()", " - dax/kmem: account for partial discontiguous resource upon removal", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - rpmsg: use generic driver_override infrastructure", " - md/raid10: reset read_slot when reusing r10bio for discard", " - RDMA/siw: bound Read Response placement to the RREAD length", " - block: skip sync_blockdev() on surprise removal in bdev_mark_dead()", " - crypto: algif_skcipher - force synchronous processing", " - crypto: crypto4xx - Remove insecure and unused rng_alg", " - crypto: hisi-trng - Remove crypto_rng interface", " - bpf: Restrict JIT predictor flush to cBPF", " - bpf: Skip redundant IBPB in pack allocator", " - bpf: Prefer packs that won't trigger an IBPB flush on allocation", " - bpf: Prefer dirty packs for eBPF allocations", " - clk: scmi: Fix clock rate rounding", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - bitops: use common function parameter names", " - media: rockchip: rga: fix too small buffer size", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - scsi: ufs: Fix wrong value printed in unexpected UPIU response case", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " - mm/fake-numa: fix under-allocation detection in uniform split", " - ext2: fix ignored return value of generic_write_sync()", " - sched: restore timer_slack_ns when resetting RT policy on fork", " - lib/test_meminit: use && for bools", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: reject FITRIM ranges shorter than a cluster", " - ocfs2/dlm: require a ref for locking_state debugfs open", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - bpf: Check tail zero of bpf_prog_info", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - wifi: wcn36xx: fix heap overflow from oversized firmware HAL response", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " - wifi: wcn36xx: fix OOB read from short trigger BA firmware response", " - ALSA: seq: Fix partial userptr event expansion", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - scsi: target: Fix hexadecimal CHAP_I handling", " - scsi: target: Remove tcm_loop target reset handling", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " - hwspinlock: qcom: avoid uninitialized struct members", " - sched/fair: Fix cpu_util runnable_avg arithmetic", " - wifi: mt76: fix argument to ieee80211_is_first_frag()", " - wifi: mt76: mt7915: fix potential tx_retries underflow", " - wifi: mt76: mt7921: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - spi: meson-spifc: fix runtime PM leak on remove", " - ASoC: codecs: aw88261: fix incorrect masks for boost regs", " - vduse: hold vduse_lock across IDR lookup in open path", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " - vduse: Requeue failed read to send_list head", " - vhost/net: complete zerocopy ubufs only once", " - tools/virtio: check mmap return value in vringh_test", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - bonding: 3ad: fix mux port state on oper down", " - ext4: fix kernel BUG in ext4_write_inline_data_end", " - selftests/bpf: Fix bpf_iter/task_vma test", " - cxl/test: Fix integer overflow in mock LSA bounds checks", " - cxl/test: Zero out LSA backing memory to avoid leaking to user", " - of: cpu: add check in __of_find_n_match_cpu_property()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " - RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " - ASoC: fsl: fsl_audmix: Validate written enum values", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " - net/sched: cls_flow: Dont expose folded kernel pointers", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " - bridge: cfm: reject invalid CCM interval at configuration time", " - sctp: validate embedded address parameter length", " - net/sched: sch_hfsc: Don't make class passive twice", " - tipc: require net admin for TIPCv2 netlink mutators", " - tipc: prevent snt_unacked underflow on CONN_ACK", " - tipc: reject inverted service ranges from peer bindings", " - cxl/test: Add check after kzalloc() memory in alloc_mock_res()", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " - crypto: rng - Free default RNG on module exit", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - power: supply: core: fix supplied_from allocations", " - handshake: Require admin permission for DONE command", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - net: wwan: t7xx: check skb_clone in control TX", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - netfilter: nf_conncount: callers must hold rcu read lock", " - ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait()", " - cifs: remove all cifs files before kill super", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - tipc: fix UAF in tipc_l2_send_msg()", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - ionic: Fix check in ionic_get_link_ext_stats", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - coresight: cti: Fix DT filter signals silently ignored", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - PCI/ASPM: Don't reconfigure ASPM entering low-power state", " - PCI: Introduce named defines for PCI ROM", " - PCI: Check ROM header and data structure addr before accessing", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - mailbox: mtk-adsp: fix UAF during device teardown", " - staging: most: video: avoid double free on video register failure", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " - iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " - iio: tcs3472: power down chip on probe failure", " - clk: at91: keep securam node alive while mapping it", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - fs/ntfs3: add bounds check to run_get_highest_vcn()", " - fs/ntfs3: fix mount failure on 64K page-size kernels", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - pNFS/filelayout: fix cheking if a layout is striped", " - xprtrdma: Remove temp allocation of rpcrdma_rep objects", " - xprtrdma: Avoid 250 ms delay on backlog wakeup", " - xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot", " - xprtrdma: Post receive buffers after RPC completion", " - xprtrdma: Use sendctx DMA state for Send signaling", " - xprtrdma: Decouple req recycling from RPC completion", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - nfs: keep PG_UPTODATE clear after read errors in page groups", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Fix bcall rep leak and unbounded peek", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - apparmor: fix rawdata_f_data implicit flex array", " - apparmor: fix potential UAF in aa_replace_profiles", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - sparc: led: avoid trimming a newline from empty writes", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - spi: dw: fix wrong BAUDR setting after resume", " - xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO", " path", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " - PCI: iproc: Restore .map_irq() for the platform bus driver", " - spi: rpc-if: Use correct device for hardware reinitialization on resume", " - virtio-net: fix len check in receive_big()", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - flow_dissector: check device type before reading ETH_ADDRS", " - ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: Fix data race between add and dump in all hash types", " - netfilter: ipset: annotate \"pos\" for concurrent readers/writers", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash", " types", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - irqchip/crossbar: Fix parent domain resource leak", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - net: marvell: prestera: initialize err in prestera_port_sfp_bind", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " - net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths", " - octeontx2-af: mcs: Fix unsupported secy stats read", " - octeontx2-pf: Clear stats of all resources when freeing resources", " - octeontx2-pf: mcs: Fix mcs resources free on PF shutdown", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: Fix stack slot index in nospec checks", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()", " - ice: fix AQ error code comparison in ice_set_pauseparam()", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - ipv4: fib: Don't ignore error route in local/main tables.", " - bpf, lsm: Add disabled BPF LSM hook list", " - bpf: Disable xfrm_decode_session hook attachment", " - netfilter: nf_nat: avoid invalid nat_net pointer use on failed", " nf_nat_init()", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - netfilter: nft_compat: ebtables emulation must reject non-bridge targets", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - NTB: epf: Report 0-based doorbell vector via ntb_db_event()", " - NTB: epf: Fix doorbell bitmask and IRQ vector handling", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - net, bpf: check master for NULL in xdp_master_redirect()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - net: mvneta: re-enable percpu interrupt on resume", " - net: sungem: fix probe error cleanup", " - net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - net: enetc: check the number of BDs needed for xdp_frame", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - apparmor: check label build before no_new_privs test", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - net/sched: sch_teql: Introduce slaves_lock to avoid race condition and", " UAF", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - cxgb4: Fix decode strings dump for T6 adapters", " - virtio_net: disable cb when NAPI is busy-polled", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - ksmbd: reject undersized DACLs before parsing ACEs", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - pinctrl: meson: restore non-sleeping GPIO access", " - net/sched: hhf: clear heavy-hitter state on reset", " - fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid", " - afs: Fix error code in afs_extract_vl_addrs()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix vllist leak", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " - afs: Fix unchecked-length string display in debug statement", " - minix: avoid overflow in bitmap block count calculation", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: convert READ_ONCE(*ptep) to ptep_get(ptep)", " - arm64/mm: convert set_pte_at() to set_ptes(..., 1)", " - arm64/mm: convert ptep_clear() to ptep_get_and_clear()", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - selftests/hid: convert the hid_bpf selftests with struct_ops", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - gue: validate REMCSUM private option length", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " - amt: fix size calculation in amt_get_size()", " - Bluetooth: 6lowpan: hold L2CAP conn across debugfs control", " - Bluetooth: MGMT: Fix adv monitor add failure cleanup", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - ring-buffer: Fix event length with forced 8-byte alignment", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: move functions to avoid forward definitions", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " - ipv6: mcast: Replace locking comments with lockdep annotations.", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " - s390/zcrypt: Remove the empty file", " - cifs: validate DFS referral string offsets", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " - dm era: fix NULL pointer dereference in metadata_open()", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " - selftests/net: fix EVP_MD_CTX leak in tcp_mmap", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - octeontx2-af: fix VF bringup affecting PF promiscuous state", " - smb: client: fix overflow in passthrough ioctl bounds check", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " - ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put", " - ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc", " - ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get", " - ASoC: SOF: topology: validate vendor array size before parsing", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " - net: atm: reject out-of-range traffic classes in QoS validation", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " - fbdev: vesafb: fix memory leak in vesafb_probe()", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " - ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get", " - ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Release reserved memory on cleanup", " - ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_cluster: reject template conntracks in hash match", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - netfilter: nf_nat_sip: reload possible stale data pointer", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " - netfilter: ecache: fix inverted time_after() check", " - netfilter: xt_nat: reject unsupported target families", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - selinux: check connect-related permissions on TCP Fast Open", " - leds: uleds: Fix potential buffer overread", " - mfd: sm501: Fix reference leak on failed device registration", " - tools/power/x86/intel-speed-select: Harden daemon pidfile open", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " - x86/boot: Reject too long acpi_rsdp= values", " - perf/x86/amd/lbr: Fix kernel address leakage", " - s390/perf_cpum_cf: Add missing array_index_nospec() to", " __hw_perf_event_init()", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: bla: reacquire gw address after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: tt: avoid request storms during pending request", " - batman-adv: fix VLAN priority offset", " - batman-adv: frag: free unfragmentable packet", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: tt: prevent TVLV OOB check overflow", " - cifs: invalidate cfid on unlink/rename/rmdir", " - mfd: tps6586x: Fix OF node refcount", " - HID: playstation: validate num_touch_reports in DualShock 4 reports", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " - nvdimm/btt: Free arenas on btt_init() error paths", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - mm/damon/core: make charge_addr_from aware of end-address exclusivity", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " - fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " - riscv: cacheinfo: Fix node reference leak in populate_cache_leaves", " - mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs()", " - mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error", " - proc: only bump parent nlink when registering directories", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - mtd: rawnand: pl353: fix probe resource allocation", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " - mtd: rawnand: fix condition in 'nand_select_target()'", " - ocfs2: avoid moving extents to occupied clusters", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " - ocfs2: add journal NULL check in ocfs2_checkpoint_inode()", " - ocfs2: reject dinodes with non-canonical i_mode type", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " - fpga: dfl: add bounds check in dfh_get_param_size()", " - bus: mhi: ep: Protect mhi_ep_handle_syserr() in the error path", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - fpga: microchip-spi: fix zero header_size OOB read in", " mpf_ops_parse_header()", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86/amd/pmc: Check for intermediate wakeup in function", " - platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops", " - platform/x86/amd/pmc: Add delay_suspend module parameter", " - smb: client: use kvzalloc() for megabyte buffer in simple fallocate", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - ice: fix ice_init_link() error return preventing probe", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - tpm: Make the TPM character devices non-seekable", " - time: Fix off-by-one in compat settimeofday() usec validation", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " - sctp: validate STALE_COOKIE cause length before reading staleness", " - nvmet-rdma: handle inline data with a nonzero offset", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " - can: bcm: add missing rcu list annotations and operations", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - net: sparx5: unregister blocking notifier on init failure", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " - dm era: fix out-of-bounds memory access for non-zero start sector", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-ioctl: fix a possible overflow in list_version_get_info", " - dm-log: fix a bitset_size overflow on 32bit machines", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm_early_create: fix freeing used table on dm_resume failure", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - scsi: sg: Report request-table problems when any status is set", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - validate control endpoint type", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - Input: ims-pcu - fix race condition in reset_device sysfs callback", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " - net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio-f7188x: Add support for NCT6126D version B", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: wwan: t7xx: destroy DMA pool on CLDMA late init failure", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - net: ena: clean up XDP TX queues when regular TX setup fails", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " - ieee802154: admin-gate legacy LLSEC dump operations", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " - batman-adv: ensure minimal ethernet header on TX", " - batman-adv: clean untagged VLAN on netdev registration failure", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - espintcp: use sk_msg_free_partial to fix partial send", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: mpfs: fix counter upload completion condition", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - net: liquidio: fix BAR resource leak on PF number failure", " - hwmon: (occ) unregister sysfs devices outside occ lock", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - net: lan743x: Initialize eth_syslock spinlock before use", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - net: wwan: iosm: bound device offsets in the MUX downlink decoder", " - hwmon: (asus_atk0110) Check package count before accessing element", " - riscv: probes: save original sp in rethook trampoline", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - drbd: reject data replies with an out-of-range payload size", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " - pmdomain: imx: Fix i.MX8MP power notifier", " - pmdomain: imx: Fix i.MX8MP VC8000E power up sequence", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - Bluetooth: btrtl: validate firmware patch bounds", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - memstick: ms_block: reject a card that reports too many blocks", " - ipvs: fix more places with wrong ipv6 transport offsets", " - ipvs: reload ip header after head reallocation", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: mac80211: free ack status frame on TX header build failure", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " - mtd: onenand: samsung: report DMA completion timeouts", " - mtd: mchp23k256: use SPI match data for chip caps", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " - perf/x86/amd/brs: Fix kernel address leakage", " - ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup", " - ACPI: bus: Introduce devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Use devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Fix possible deadlock and missing notifications", " - iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - iio: invensense: remove redundant initialization of variable period", " - iio: invensense: fix timestamp glitches when switching frequency", " - iio: imu: inv_icm42600: stabilized timestamp in interrupt", " - iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading", " - iio: pressure: mpl115: fix runtime PM leak on read error", " - bitops: make BYTES_TO_BITS() treewide-available", " - iio: common: st_sensors: honour channel endianness in read_axis_data", " - ALSA: aoa: check snd_ctl_new1() return value", " - PCI: altera: Fix resource leaks on probe failure", " - vfio/mlx5: Fix racy bitfields and tighten struct layout", " - PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling", " - PCI: controller: Use dev_fwnode() instead of of_fwnode_handle()", " - PCI: mediatek: Convert bool to single quirks entry and bitmap", " - PCI: mediatek: Use generic MACRO for TPVPERL delay", " - PCI: mediatek: Fix IRQ domain leak when port fails to enable", " - PCI: Prevent resource tree corruption when BAR resize fails", " - PCI: Free saved list without holding pci_bus_sem", " - PCI: Fix restoring BARs on BAR resize rollback path", " - PCI: Add kerneldoc for pci_resize_resource()", " - PCI: Move Resizable BAR code to rebar.c", " - PCI: Skip Resizable BAR restore on read error", " - staging: rtl8723bs: core: move constants to right side in comparison", " - staging: rtl8723bs: fix spaces around binary operators", " - staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),", " rtw_get_wapi_ie(), and rtw_get_wps_attr()", " - crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()", " - Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref", " - mm/shrinker: do not hold RCU lock in shrinker_debugfs_count_show()", " - coresight: etb10: restore atomic_t for shared reading state", " - gpio: sch: use raw_spinlock_t in the irq startup path", " - media: nxp: imx8-isi: Convert to platform remove callback returning void", " - media: nxp: imx8-isi: use devm_pm_runtime_enable() to simplify code", " - media: nxp: imx8-isi: Fix use-after-free on remove", " - netfilter: ebtables: Use vmalloc_array() to improve code", " - netfilter: ebtables: zero chainstack array", " - Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - smb: client: Improve unlocking of a mutex in cifs_get_swn_reg()", " - smb: client: resolve SWN tcon from live registrations", " - ksmbd: use opener credentials for FSCTL mutations", " - ksmbd: centralize ksmbd_conn final release to plug transport leak", " - ksmbd: track the connection owning a byte-range lock", " - proc: rename proc_setattr to proc_nochmod_setattr", " - proc: protect ptrace_may_access() with exec_update_lock (FD links)", " - writeback: fix race between cgroup_writeback_umount() and", " inode_switch_wbs()", " - perf/x86/intel/uncore: Defer ADL global PMON enable to enable_box()", " - HID: add haptics page defines", " - HID: multitouch: fix out-of-bounds bit access on mt_io_flags", " - mm/slab: do not limit zeroing to orig_size when only red zoning is", " enabled", " - seqlock: Introduce scoped_seqlock_read()", " - seqlock: Change do_task_stat() to use scoped_seqlock_read()", " - proc: protect ptrace_may_access() with exec_update_lock (part 1)", " - treewide: Switch/rename to timer_delete[_sync]()", " - HID: appleir: fix UAF on pending key_up_timer in remove()", " - serial: 8250_mid: Disable DMA for selected platforms", " - hfs/hfsplus: prevent getting negative values of offset/length", " - hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length", " - bpf: Consistently use bpf_rcu_lock_held() everywhere", " - bpf: Allow LPM map access from sleepable BPF programs", " - usb: iowarrior: remove inherent race with minor number", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - usb: typec: tcpm: Fix VDM type for Enter Mode commands", " - crypto: atmel - Drop explicit initialization of struct", " i2c_device_id::driver_data to 0", " - crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A", " - usb: gadget: f_fs: initialize reset_work at allocation time", " - nvmet: return DHCHAP status codes from nvmet_setup_auth()", " - nvmet-auth: validate reply message payload bounds against transfer", " length", " - usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile", " - btrfs: check and set EXTENT_DELALLOC_NEW before clearing EXTENT_DELALLOC", " - crypto: qat - fix restarting state leak on allocation failure", " - audit: add audit_log_nf_skb helper function", " - audit: fix potential integer overflow in audit_log_n_hex()", " - regulator: scmi: Simplify with scoped for each OF child loop", " - regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()", " - mm: do file ownership checks with the proper mount idmap", " - exfat: move free cluster out of exfat_init_ext_entry()", " - exfat: remove unnecessary read entry in __exfat_rename()", " - exfat: rename argument name for exfat_move_file and exfat_rename_file", " - exfat: add exfat_get_dentry_set_by_ei() helper", " - exfat: move exfat_chain_set() out of __exfat_resolve_path()", " - exfat: preserve benign secondary entries during rename and move", " - btrfs: fix false IO failure after falling back to buffered write", " - btrfs: fix incorrect buffered IO fallback for append direct writes", " - Bluetooth: hci_core: Enable buffer flow control for SCO/eSCO", " - Bluetooth: separate CIS_LINK and BIS_LINK link types", " - Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - seqlock: fix scoped_seqlock_read kernel-doc", " - Bluetooth: hci_core: Remove check of BDADDR_ANY in", " hci_conn_hash_lookup_big_state", " - Bluetooth: hci_sync: Fix attempting to send HCI_Disconnect to BIS handle", " - Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote", " netdev", " - selftests/hid: ensure CKI can compile our new tests on old kernels", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error harder", " - Bluetooth: btmtk: remove #ifdef around declarations", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - jiffies: Define secs_to_jiffies()", " - jiffies: Cast to unsigned long in secs_to_jiffies() conversion", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - tools/testing: add linux/args.h header and fix radix, VMA tests", " - selftests/bpf: Add simple strscpy() implementation", " - bcachefs: avoid truncating fiemap extent length", " - gpio: rockchip: change the GPIO version judgment logic", " - gpio: rockchip: teardown bugs and resource leaks", " - gpio: rockchip: fix generic IRQ chip leak on remove", " - NFSv4/flexfiles: Remove cred local variable dependency", " - iio: resolver: ad2s1210: notify trigger and clear state on fault read", " error", " - iio: temperature: Build mlx90635 with CONFIG_MLX90635", " - vfio: Remove device debugfs before releasing devres", " - PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000", " series", " - netpoll: fix a use-after-free on shutdown path", " - mm: shrinker: fix shrinker_info teardown race with expansion", " - NFSv4/flexfiles: Add data structure support for striped layouts", " - mm/khugepaged: write all dirty file folios when collapsing", " - platform/x86: intel-hid: Protect ACPI notify handler against recursion", " - Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled", " - Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()", " - fs/ntfs3: rename ni_readpage_cmpr into ni_read_folio_cmpr", " - ksmbd: use __GFP_RETRY_MAYFAIL", " - ksmbd: use opener credentials for ADS I/O", " - cpufreq: Make cpufreq_driver->exit() return void", " - cpufreq: qcom-cpufreq-hw: Fix possible double free", " - nvme: target: rdma: fix ndev refcount leak on queue connect", " - nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page", " - crypto: qat - keep VFs enabled during reset", " - crypto: qat - notify fatal error before AER reset preparation", " - crypto: qat - protect service table iterations with service_lock", " - selftests/mm: pagemap_ioctl: use the correct page size for", " transact_test()", " - iommufd: Set upper bounds on cache invalidation entry_num and entry_len", " - iommu/amd: Don't split flush for amd_iommu_domain_flush_all()", " - dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning", " - i2c: core: fix adapter probe deferral loop", " - xfs: fix null pointer dereference in tracepoint", " - xfs: don't wrap around quota ids in dqiterate", " - xfs: clamp timestamp nanoseconds correctly", " - xfs: don't zap bmbt forks if they are MAXLEVELS tall", " - iommu/vt-d: Clear Present bit before tearing down context entry", " - iommu: Pass old domain to set_dev_pasid op", " - iommu/vt-d: Cleanup intel_context_flush_present()", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " - vsock/virtio: bind uarg before filling zerocopy skb", " - iommu/amd: Use maximum Event log buffer size when SNP is enabled on", " Family 0x19", " - iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family", " 0x19", " - net: dropreason: Gather SOCKET_ drop reasons.", " - af_unix: Set drop reason in unix_release_sock().", " - af_unix: Set drop reason in manage_oob().", " - af_unix: Set drop reason in unix_stream_read_skb().", " - af_unix/scm: fix whitespace errors", " - af_unix: Don't hold unix_state_lock() in __unix_dgram_recvmsg().", " - af_unix: Don't check SOCK_DEAD in unix_stream_read_skb().", " - af_unix: Don't use skb_recv_datagram() in unix_stream_read_skb().", " - af_unix: Drop all SCM attributes for SOCKMAP.", " - time/jiffies: Change register_refined_jiffies() to void __init", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - media: uvcvideo: Do not add clock samples with small sof delta", " - serial: max310x: replace bare use of 'unsigned' with 'unsigned int'", " (checkpatch)", " - serial: max310x: implement gpio_chip::get_direction()", " - drm/gpuvm: Do not prepare NULL objects", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - soc: xilinx: Shutdown and free rx mailbox channel", " - crypto: qat - fix heartbeat error injection", " - memory: tegra: Wire up system sleep PM ops", " - drm/gpuvm: take refcount on DRM device", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - RDMA/hns: Initialize seqfile before creating file", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - RDMA/hns: Fix log flood after cmd_mbox failure", " - net: introduce page_frag_cache_drain()", " - nvmet-tcp: fix page fragment cache leak in error path", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - driver core: Use system_percpu_wq instead of system_wq", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - x86/cpu/amd: Provide a separate accessor for Node ID", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - netfilter: nfnetlink_cthelper: use {READ,WRITE}_ONCE for accessing", " helper flags", " - netfilter: synproxy: drop packets if timestamp adjustment fails", " - netfilter: synproxy: adjust duplicate timestamp options", " - netfilter: synproxy: fix unaligned memory access in timestamp adjustment", " - RDMA/siw: Fix endpoint/socket association handling", " - riscv: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - virtio_console: read size from config space during device init", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - net: dsa: qca8k: fix led devicename when using external mdio bus", " - ALSA: seq: Drop superfluous filter argument of get_event_dest_client()", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - dpll: add reference-sync netlink attribute", " - dpll: move xa_erase() call in to match dpll_pin_alloc() error path order", " - dpll: add reference sync get/set", " - dpll: Allow associating dpll pin with a firmware node", " - dpll: Add notifier chain for dpll events", " - dpll: Support dynamic pin index allocation", " - dpll: Enhance and consolidate reference counting logic", " - dpll: fix stale iteration in dpll_pin_on_pin_unregister()", " - dpll: send delete notification before unregister in on-pin rollback", " - dpll: emit per-dpll delete notifications in dpll_pin_on_pin_unregister()", " - dpll: guard sync-pair removal on full pin unregister", " - dpll: balance create/delete notifications in __dpll_pin_(un)register", " - landlock: Fix unmarked concurrent access to socket family", " - selftests/bpf: Fix typo in verify_umulti_link_info", " - udf: fix nls leak on udf_fill_super() failure", " - mfd: rsmu: Fix page register setup", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: split ep_insert() into alloc + register stages", " - eventpoll: extract ep_deliver_event() from ep_send_events()", " - eventpoll: wrap EP_UNACTIVE_PTR in typed sentinel helpers", " - eventpoll: rename epi->next and txlist for clarity", " - eventpoll: Fix epoll_wait() report false negative", " - gpiolib: acpi: Only trigger ActiveBoth interrupts on boot", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - PCI: meson: Add missing remove callback", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - workqueue: Add new WQ_PERCPU flag", " - i3c: master: add WQ_PERCPU to alloc_workqueue users", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - xfrm: Fix xfrm state cache insertion race", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - netfilter: ipset: make sure gc is properly stopped", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: hugetlb_reparenting_test: do not unmount", " - selftests/mm: save and restore nr_hugepages value", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - ipv6: annotate data-races around cnf.forwarding", " - ipv6/addrconf: annotate data-races around devconf fields (II)", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_info", " - ice: dpll: fix memory leak in ice_dpll_init_info error paths", " - net: bnxt: use ethtool string helpers", " - eth: bnxt: gather and report HW-GRO stats", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - ipv6: Add __in6_dev_get_rtnl_net().", " - octeontx2-af: Validate NIX maximum LFs correctly", " - udp_tunnel: remove rtnl_lock dependency", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - net: hisilicon: hns3: use ethtool string helpers", " - net: hns3: use string choices helper", " - net: hns3: use hns3_get_ae_dev() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: use hns3_get_ops() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: clear hns alarm: comparison of integer expressions of", " different signedness", " - net: hns3: unify copper port ksettings configuration path", " - net: hns3: refactor MAC autoneg and speed configuration", " - net: hns3: fix permanent link down deadlock after reset", " - net: hns3: differentiate autoneg default values between copper and fiber", " - rtnetlink: Add per-netns RTNL.", " - [Config] Set CONFIG_DEBUG_NET_SMALL_RTNL=n", " - rtnetlink: Add assertion helpers for per-netns RTNL.", " - rtnetlink: Define rtnl_net_trylock().", " - ipv6: Convert net.ipv6.conf.${DEV}.XXX sysctl to per-netns RTNL.", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Make /afs/. as well as /afs/ mountpoints", " - afs: Add rootcell checks", " - afs: Make /afs/@cell and /afs/.@cell symlinks", " - afs: Fix afs_atcell_get_link() to handle RCU pathwalk", " - afs: Remove the \"autocell\" mount option", " - afs: Change dynroot to create contents on demand", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - ovl: fix comment about locking order", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - afs: Convert comma to semicolon", " - afs: Fix double netfs initialisation in afs_root_iget()", " - drm/xe: Add warn when level can not be zero.", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - HID: bpf: Fix hid_bpf_get_data() range check", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - genirq/generic_chip: Introduce irq_domain_{alloc,remove}_generic_chips()", " - gpio: mvebu: free generic chips on unbind", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " - drm/xe: remove duplicate include", " - LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()", " - LoongArch: KVM: Check the return values for put_user()", " - LoongArch: KVM: Fix FPU register width with user access API", " - LoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr()", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - fbdev: efifb: fix memory leak in efifb_probe()", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - batman-adv: mcast: avoid OOB read of num_dests header", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()", " - fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry()", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - taskstats: retain dead thread stats in TGID queries", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - NFS: Charge unstable writes by request size, not folio size", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: make error counter atomic", " - accel/ivpu: Reject firmware log with size smaller than header", " - firmware_loader: introduce __free() cleanup hanler", " - Input: ims-pcu - fix firmware leak in async update", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - gpio: tegra: do not call pinctrl for GPIO direction", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - s390: Revert support for DCACHE_WORD_ACCESS", " - [Config] Set CONFIG_DCACHE_WORD_ACCESS=- for s390x", " - selftests: net: make busywait timeout clock portable", " - ata: libata: Use QUIRK instead of HORKAGE", " - ata: libata-core: Skip HPA resize for locked drives", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - ALSA: hda/cs35l41: Fix firmware load work teardown", " - io_uring/rw: ensure reissue path is correctly handled for IOPOLL", " - io_uring/rw: preserve partial result for iopoll", " - Bluetooth: L2CAP: Fix not tracking outstanding TX ident", " - mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless", " host", " - ksmbd_vfs_rename(): vfs_path_parent_lookup() accepts ERR_PTR() as name", " - vfs: make LAST_XXX private to fs/namei.c", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " - HID: pidff: Fix missing blank lines after declarations", " - HID: pidff: Add missing spaces", " - HID: pidff: Rework pidff_upload_effect", " - HID: pidff: Use correct effect type in effect update", " - bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()", " - USB: iowarrior: fix use-after-free on disconnect race", " - crypto: atmel-sha204a - fail on hwrng registration error in probe path", " - btrfs: concentrate the error handling of submit_one_sector()", " - btrfs: remove folio parameter from ordered io related functions", " - btrfs: remove the COW fixup mechanism", " - slab: Introduce kmalloc_obj() and family", " - slab: Introduce kmalloc_flex() and family", " - add default_gfp() helper macro and use it in the new *alloc_obj()", " helpers", " - default_gfp(): avoid using the \"newfangled\" __VA_OPT__ trick", " - slab: recognize @GFP parameter as optional in kernel-doc", " - fscrypt: Fix key setup in edge case with multiple data unit sizes", " - fscrypt: Replace mk_users keyring with simple list", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is", " uninitialized", " - rtnetlink: Make per-netns RTNL dereference helpers to macro.", " - afs: Fix afs_atcell_get_link() to check if ws_cell is unset first", " - afs: Fix afs_dynroot_readdir() to not use the RCU read lock", " - udp_tunnel: fix deadlock in udp_tunnel_nic_set_port_priv()", " - i40e: drop udp_tunnel_get_rx_info() call from i40e_open()", " - ice: drop udp_tunnel_get_rx_info() call from ndo_open()", " - Bluetooth: L2CAP: Fix regressions caused by reusing ident", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " - perf: Reject exited events as group leaders", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - proc: Fix broken error paths for namespace links", " - Upstream stable to v6.6.145, v6.12.96, v6.12.97", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2026-53365", " - vsock/virtio: fix zerocopy completion for multi-skb sends", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two", " - x86/mm: Fix check/use ordering in switch_mm_irqs_off()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192)", " - debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING", " - debugobjects: Use LD_WAIT_CONFIG instead of LD_WAIT_SLEEP", " - debugobjects: Dont call fill_pool() in early boot hardirq context", " - ARM: group is_permission_fault() with is_translation_fault()", " - ARM: allow __do_kernel_fault() to report execution of memory faults", " - ARM: fix branch predictor hardening", " - RDMA/bnxt_re: zero shared page before exposing to userspace", " - selftests/bpf: Add test to ensure kprobe_multi is not sleepable", " - bpf: Remove mark_precise_scalar_ids()", " - selftests/bpf: Tests for per-insn sync_linked_regs() precision tracking", " - selftests/bpf: Update comments find_equal_scalars->sync_linked_regs", " - hv: utils: handle and propagate errors in kvp_register", " - Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs", " - phonet: Pass ifindex to fill_addr().", " - phonet: Pass net and ifindex to phonet_address_notify().", " - scripts/sorttable: Remove unused macro defines", " - scripts/sorttable: Remove unused write functions", " - scripts/sorttable: Remove unneeded Elf_Rel", " - scripts/sorttable: Have the ORC code use the _r() functions to read", " - scripts/sorttable: Make compare_extable() into two functions", " - scripts/sorttable: Convert Elf_Ehdr to union", " - scripts/sorttable: Replace Elf_Shdr Macro with a union", " - scripts/sorttable: Convert Elf_Sym MACRO over to a union", " - scripts/sorttable: Add helper functions for Elf_Ehdr", " - scripts/sorttable: Add helper functions for Elf_Shdr", " - scripts/sorttable: Add helper functions for Elf_Sym", " - scripts/sorttable: Use uint64_t for mcount sorting", " - scripts/sorttable: Move code from sorttable.h into sorttable.c", " - scripts/sorttable: Get start/stop_mcount_loc from ELF file directly", " - scripts/sorttable: Use a structure of function pointers for elf helpers", " - arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64", " - [Config] Set configs to sort mcount_loc at boot for arm64", " - scripts/sorttable: Have mcount rela sort use direct values", " - scripts/sorttable: Always use an array for the mcount_loc sorting", " - scripts/sorttable: Zero out weak functions in mcount_loc table", " - ftrace: Update the mcount_loc check of skipped entries", " - ftrace: Have ftrace pages output reflect freed pages", " - ftrace: Do not over-allocate ftrace memory", " - ftrace: Test mcount_loc addr before calling ftrace_call_addr()", " - ftrace: Check against is_kernel_text() instead of kaslr_offset()", " - scripts/sorttable: Use normal sort if theres no relocs in the mcount", " section", " - scripts/sorttable: Allow matches to functions before function entry", " - scripts/sorttable: Fix endianness handling in build-time mcount sort", " - file: add fput() cleanup helper", " - eventpoll: use hlist_is_singular_node() in __ep_remove()", " - Revert \"ptp: add testptp mask test\"", " - Bluetooth: btmtk: validate WMT event SKB length before struct access", " - Bluetooth: btmtk: accept too short WMT FUNC_CTRL events", " - batman-adv: tp_meter: keep unacked list in ascending ordered", " - batman-adv: tp_meter: initialize dup_acks explicitly", " - batman-adv: tp_meter: initialize dec_cwnd explicitly", " - batman-adv: tp_meter: avoid window underflow", " - batman-adv: tp_meter: fix fast recovery precondition", " - batman-adv: tp_meter: handle seqno wrap-around for fast recovery", " detection", " - batman-adv: tp_meter: add only finished tp_vars to lists", " - batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE", " - batman-adv: prevent ELP transmission interval underflow", " - batman-adv: tp_meter: initialize last_recv_time during init", " - batman-adv: ensure bcast is writable before modifying TTL", " - batman-adv: fix (m|b)cast csum after decrementing TTL", " - batman-adv: frag: ensure fragment is writable before modifying TTL", " - batman-adv: frag: avoid underflow of TTL", " - batman-adv: tp_meter: annotate last_recv_time access with", " READ/WRITE_ONCE", " - batman-adv: tp_meter: prevent parallel modifications of last_recv", " - batman-adv: tp_meter: handle overlapping packets", " - batman-adv: tt: don't merge change entries with different VIDs", " - batman-adv: tt: track roam count per VID", " - batman-adv: dat: prevent false sharing between VLANs", " - batman-adv: tvlv: enforce 2-byte alignment", " - batman-adv: tvlv: avoid race of cifsnotfound handler state", " - inet: add indirect call wrapper for getfrag() calls", " - err.h: use __always_inline on all error pointer helpers", " - wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S", " - wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor", " - wifi: rtw88: increase TX report timeout to fix race condition", " - wifi: iwlwifi: mvm: fix race condition in PTP removal", " - f2fs: fix to round down start offset of fallocate for pin file", " - f2fs: keep atomic write retry from zeroing original data", " - MIPS: DEC: Prevent initial console buffer from landing in XKPHYS", " - fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode", " - nfsd: check get_user() return when reading princhashlen", " - NFS: Prevent resource leak in nfs_alloc_server()", " - serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero", " - wifi: mt76: mt7921: avoid undesired changes of the preset regulatory", " domain", " - ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()", " - xfs: fix error returns in CoW fork repair", " - locking/mutex: Remove wakeups from under mutex::wait_lock", " - net: ipv6: Make udp_tunnel6_xmit_skb() void", " - Revert \"PCI: qcom: Advertise Hotplug Slot Capability with no Command", " Completion support\"", " - KVM: SEV: Ignore MMIO requests of length '0'", " - mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program", " - mtd: spi-nor: macronix: add support for mx66{l2, u1}g45g", " - LoongArch: Report dying CPU to RCU in stop_this_cpu()", " - MIPS: smp: report dying CPU to RCU in stop_this_cpu()", " - locking: rtmutex: Fix wake_q logic in task_blocks_on_rt_mutex", " - bonding: annotate data-races arcound churn variables", " - Upstream stable to v6.6.144, v6.12.95", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53389", " - net/tcp-ao: fix use-after-free of key in del_async path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53393", " - nfsd: reset write verifier on deferred writeback errors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53400", " - i2c: core: fix adapter registration race", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63806", " - KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with", " get_unaligned()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63940", " - KVM: SEV: Ignore Port I/O requests of length '0'", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53387", " - iio: light: veml6075: add bounds check to veml6075_it_ms index", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53070", " - sctp: disable BH before calling udp_tunnel_xmit_skb()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43216", " - net: Drop the lock in skb_may_tx_timestamp()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64244", " - drivers/base/memory: set mem->altmap after successful device", " registration", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53384", " - serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53390", " - ksmbd: fix out-of-bounds read in smb_check_perm_dacl()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53391", " - NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53397", " - nfsd: fix posix_acl leak on SETACL decode failure", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64245", " - fbdev: modedb: fix a possible UAF in fb_find_mode()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53403", " - fbdev: Fix fb_new_modelist to prevent null-ptr-deref in", " fb_videomode_to_var", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64246", " - power: reset: linkstation-poweroff: fix use-after-free in the", " linkstation_poweroff_init()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63794", " - KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64247", " - KVM: x86: hyper-v: Bound the bank index when querying sparse banks", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63795", " - 9p: avoid putting oldfid in p9_client_walk() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63796", " - ocfs2: reject oversized group bitmap descriptors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63797", " - rpmsg: char: Fix use-after-free on probe error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64249", " - fpga: region: fix use-after-free in child_regions_with_firmware()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63798", " - irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup", " on remove", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63801", " - tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63802", " - blk-cgroup: fix UAF in __blkcg_rstat_flush()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63803", " - hdlc_ppp: sync per-proto timers before freeing hdlc state", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63804", " - gfs2: fix use-after-free in gfs2_qd_dealloc", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63809", " - bpf: use kvfree() for replaced sysctl write buffer", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63812", " - f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63814", " - f2fs: validate ACL entry sizes in f2fs_acl_from_disk()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63817", " - f2fs: validate compress cache inode only when enabled", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63821", " - wifi: rtw88: usb: fix memory leaks on USB write failures", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63822", " - wifi: ath11k: fix warning when unbinding", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63823", " - keys: Pin request_key_auth payload in instantiate paths", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63824", " - KEYS: fix overflow in keyctl_pkey_params_get_2()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63826", " - fbdev: fix use-after-free in store_modes()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64254", " - NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG", " share BAR", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63827", " - apparmor: fix use-after-free in rawdata dedup loop", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63828", " - apparmor: mediate the implicit connect of TCP fast open sendmsg", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63830", " - net: skmsg: preserve sg.copy across SG transforms", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63831", " - mac802154: llsec: add skb_cow_data() before in-place crypto", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53361", " - af_unix: Set gc_in_progress to true in unix_gc().", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63833", " - ntfs3: reject direct userspace writes to reserved $LX* xattrs", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53366", " - ipv4: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53362", " - ipv6: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63834", " - batman-adv: tp_meter: restrict number of unacked list entries", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63835", " - batman-adv: v: prevent OGM aggregation on disabled hardif", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63836", " - batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63807", " - KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping", " level", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53381", " - virtiofs: fix UAF on submount umount", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53382", " - media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53383", " - ksmbd: reject non-VALID session in compound request branch", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53385", " - vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent", " vcs_write", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53388", " - fuse: re-lock request before replacing page cache folio", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53157", " - net: phonet: free phonet_device after RCU grace period", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53163", " - locking/rtmutex: Skip remove_waiter() when waiter is not enqueued", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2025-23131", " - dlm: prevent NPD when writing a positive value to event_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-46252", " - regulator: core: fix locking in regulator_resolve_supply() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52928", " - af_unix: Reject SIOCATMARK on non-stream sockets", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43010", " - bpf: Reject sleepable kprobe_multi programs at attach time", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53325", " - agp/amd64: Fix broken error propagation in agp_amd64_probe()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64188", " - net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64191", " - i2c: stub: Reject I2C block transfers with invalid length", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53327", " - debugobjects: Do not fill_pool() if pi_blocked_on", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52909", " - ip6_vti: set netns_immutable on the fallback device.", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53167", " - fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios", "" ], "package": "linux", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 11:03:24 +0200" }, { "cves": [ { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-146.146 -proposed tracker (LP: #2166353)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", "", " * Bluetooth fails to initialize due to a kernel NULL pointer error", " (LP: #2165873)", " - Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c", "", " * Dell Precision fails to shutdown when HDMI display is connected (22.04", " HWE) (LP: #2164507)", " - drm/i915/vbt: Add fields dedicated_external and dyn_port_over_tc", " - drm/i915/display: Handle dedicated external ports in", " intel_encoder_is_tc()", "", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", "", " * [SRU] HPE: Fix for UBSAN array-index-out-of-bounds (LP: #2161004)", " - x86/platform/uv: Fix UBSAN array-index-out-of-bounds", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough", " (LP: #2089306)", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Reboot machine with ext4 configured to data=journal could dump spurious", " call trace (LP: #2164716)", " - ext4: clear stale xarray tags on folios skipped during writeback", "", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", "", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796)", " - netfilter: bitwise: rename some boolean operation functions", " - netfilter: bitwise: add support for doing AND, OR and XOR directly", " - drm/fbdev-helper: Set and clear VGA switcheroo client from fb_info", " - arm64: io: Rename ioremap_prot() to __ioremap_prot()", " - Disable -Wattribute-alias for clang-23 and newer", " - netfilter: xt_NFQUEUE: prefer raw_smp_processor_id", " - drm/imx: Fix three kernel-doc warnings in dcss-scaler.c", " - pcnet32: stop holding device spin lock during napi_complete_done", " - net: Annotate sk->sk_write_space() for UDP SOCKMAP.", " - net: lan743x: permit VLAN-tagged packets up to configured MTU", " - net: fec: fix pinctrl default state restore order on resume", " - Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame()", " extension handling", " - Bluetooth: MGMT: Fix backward compatibility with userspace", " - ptp: vclock: Switch from RCU to SRCU", " - octeontx2-af: npc: Fix CPT channel mask in npc_install_flow", " - vxlan: vnifilter: send notification on VNI add", " - vxlan: vnifilter: fix spurious notification on VNI update", " - ipmi: Fix rcu_read_unlock to srcu_read_unlock in handle_read_event_rsp", " - time: Fix off-by-one in settimeofday() usec validation", " - tools/rv: Fix cleanup after failed trace setup", " - arm64: tlb: Allow XZR argument to TLBI ops", " - iomap: don't revert iov_iter on partially completed buffered writes", " - net/mlx4: avoid GCC 10 __bad_copy_from() false positive", " - r8152: handle the return value of usb_reset_device()", " - rds: mark snapshot pages dirty in rds_info_getsockopt()", " - net: mvpp2: Add metadata support for xdp mode", " - net: mvpp2: build skb from XDP-adjusted data on XDP_PASS", " - clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time", " - tracing/probes: Point the error offset correctly for eprobe argument", " error", " - mmc: litex_mmc: Use DIV_ROUND_UP for more accurate clock calculation", " - USB: serial: option: add usb-id for Dell Wireless DW5826e-m", " - ALSA: timer: Fix UAF at snd_timer_user_params()", " - drm/amd/display: Reject gpio_bitshift >= 32 in", " bios_parser_get_gpio_pin_info()", " - mm/damon/ops-common: call folio_test_lru() after folio_get()", " - ARM: socfpga: Fix OF node refcount leak in SMP setup", " - ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O", " - mptcp: fix retransmission loop when csum is enabled", " - mptcp: sockopt: check timestamping ret value", " - selftests: mptcp: add test for extra_subflows underflow on userspace PM", " - ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write", " - inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush", " - pidfd: refuse access to tasks that have started exiting harder", " - i2c: stm32f7: fix timing computation ignoring i2c-analog-filter", " - i2c: tegra: Fix NOIRQ suspend/resume", " - Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)", " - Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard", " - net/mlx5: Reorder completion before putting command entry in", " cmd_work_handler", " - net: mv643xx: fix OF node refcount", " - octeontx2-af: fix memory leak in rvu_setup_hw_resources()", " - mmc: core: Fix host controller programming for fixed driver type", " - mmc: litex_mmc: Set mandatory idle clocks before CMD0", " - mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC", " - mmc: sdhci: add signal voltage switch in sdhci_resume_host", " - slimbus: qcom-ngd-ctrl: fix OF node refcount", " - drm/amdgpu: restart the CS if some parts of the VM are still invalidated", " - fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling", " - driver core: reject devices with unregistered buses", " - mm/hugetlb: avoid false positive lockdep assertion", " - soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get()", " - ipmi:ssif: Remove unnecessary indention", " - ipmi:ssif: NULL thread on error", " - selftests: mptcp: drop nanoseconds width specifier", " - tty: serial: samsung: use u32 for register interactions", " - RDMA/umem: fix kernel-doc warnings", " - RDMA: Move DMA block iterator logic into dedicated files", " - arm64: cputype: Add NVIDIA Olympus definitions", " - arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU", " - mptcp: add-addr: always drop other suboptions", " - mptcp: fix missing wakeups in edge scenarios", " - Revert \"selftest/ptp: update ptp selftest to exercise the gettimex", " options\"", " - ARM: fix hash_name() fault", " - wifi: remove zero-length arrays", " - soc: qcom: ice: Return -ENODEV if the ICE platform device is not found", " - Bluetooth: ISO: Fix not using bc_sid as advertisement SID", " - octeontx2-pf: Fix NDC sync operation errors", " - octeontx2-af: Fix initialization of mcam's entry2target_pffunc field", " - ima: kexec: skip IMA segment validation after kexec soft reboot", " - ima: kexec: move IMA log copy from kexec load to execute", " - gpio: zynq: fix runtime PM leak on remove", " - writeback: Avoid contention on wb->list_lock when switching inodes", " - writeback: Fix use after free in inode_switch_wbs_work_fn()", " - xfrm: hold device only for the asynchronous decryption", " - KVM: VMX: Update SVI during runtime APICv activation", " - drm/xe: fix refcount leak in xe_range_fence_insert()", " - slimbus: qcom-ngd-ctrl: Fix up platform_driver registration", " - slimbus: qcom-ngd-ctrl: Fix probe error path ordering", " - slimbus: qcom-ngd-ctrl: Initialize controller resources in controller", " - slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership", " - slimbus: qcom-ngd-ctrl: Balance pm_runtime enablement for NGD", " - drm/amd/pm: fix smu13 power limit default/cap calculation", " - drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in", " set_soft_freq_limited_range", " - drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs", " - mailbox: Fix NULL message support in mbox_send_message()", " - vsock/virtio: fix skb overhead accounting to preserve full buf_alloc", " - net: introduce EXPORT_IPV6_MOD() and EXPORT_IPV6_MOD_GPL()", " - mptcp: pm: fix extra_subflows underflow on userspace PM subflow creation", " - vsock/virtio: fix skb overhead overflow on 32-bit builds", " - Upstream stable to v6.6.143, v6.12.94", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53132", " - vsock/virtio: fix potential unbounded skb queue", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53138", " - drm/amd/display: Bound VBIOS record-chain walk loops", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53140", " - drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53332", " - slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53156", " - nvmem: core: fix use-after-free bugs in error paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53202", " - accel/ivpu: Fix signed integer truncation in IPC receive", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53205", " - accel/ivpu: Add bounds checks for firmware log indices", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53210", " - tee: shm: fix shm leak in register_shm_helper()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-31663", " - xfrm: hold dev ref until after transport_finish NF_HOOK", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53220", " - netfilter: revalidate bridge ports", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53229", " - net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46203", " - spi: cadence-quadspi: fix unclocked access on unbind", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63871", " - Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53251", " - Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63869", " - wifi: mac80211: limit injected antenna index in", " ieee80211_parse_tx_radiotap", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53261", " - devlink: Release nested relation on devlink free", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53262", " - l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses", " - arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-45850", " - ipvs: skip ipv6 extension headers for csum checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53133", " - RDMA/umem: Fix truncation for block sizes >= 4G", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52908", " - RDMA: During rereg_mr ensure that REREG_ACCESS is compatible", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53199", " - hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53134", " - netfilter: nft_fib: fix stale stack leak via the OIFNAME register", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63883", " - serial: qcom_geni: fix kfifo underflow when flush precedes DMA", " completion IRQ", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64528", " - tty: serial: samsung: Remove redundant port lock acquisition in rx", " helpers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53329", " - drm/amd/display: Use krealloc_array() in dal_vector_reserve()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53135", " - drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53136", " - drm/amd/display: Clamp VBIOS HDMI retimer register count to array size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53137", " - drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53143", " - drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on", " GFX11", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53144", " - drm/amdkfd: fix NULL dereference in get_queue_ids()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53331", " - slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53146", " - thunderbolt: Limit XDomain response copy to actual frame size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53147", " - thunderbolt: Validate XDomain request packet size before type cast", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53148", " - thunderbolt: Clamp XDomain response data copy to allocation size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53149", " - thunderbolt: Bound root directory content to block size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53150", " - thunderbolt: Reject zero-length property entries in validator", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52929", " - sctp: stream: fully roll back denied add-stream state", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52917", " - sctp: diag: reject stale associations in dump_one path", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53154", " - mm/hugetlb: restore reservation on error in hugetlb folio copy paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53336", " - nvmem: layouts: onie-tlv: fix hang on unknown types", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53337", " - net: bonding: fix NULL pointer dereference in bond_do_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53158", " - misc: fastrpc: Fix NULL pointer dereference in rpmsg callback", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53159", " - misc: fastrpc: fix DMA address corruption due to find_vma misuse", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53160", " - misc: fastrpc: fix use-after-free race in fastrpc_map_create", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53161", " - misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52930", " - ipc/shm: serialize orphan cleanup with shm_nattch updates", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53339", " - i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53168", " - fuse: reject fuse_notify() pagecache ops on directories", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53177", " - bnxt_en: Fix NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53181", " - vsock/vmci: fix sk_ack_backlog leak on failed handshake", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53182", " - wifi: nl80211: reject oversized EMA RNR lists", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53183", " - mptcp: allow subflow rcv wnd to shrink", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63867", " - mptcp: close TOCTOU race while computing rcv_wnd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53343", " - ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53184", " - udp: clear skb->dev before running a sockmap verdict", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53185", " - zram: fix use-after-free in zram_bvec_write_partial()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53190", " - drm/virtio: fix dma_fence refcount leak on error in", " virtio_gpu_dma_fence_wait()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53194", " - USB: serial: kl5kusb105: fix bulk-out buffer overflow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53195", " - USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53196", " - USB: serial: io_ti: fix heap overflow in get_manuf_info()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52935", " - xfrm: espintcp: do not reuse an in-progress partial send", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53198", " - ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53356", " - drm/i915/gem: Fix phys BO pread/pwrite with offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53345", " - KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53208", " - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53209", " - Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53213", " - drm/vc4: fix krealloc() memory leak", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53347", " - drm/virtio: Fix driver removal with disabled KMS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43116", " - netfilter: ctnetlink: ensure safe access to master conntrack", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53214", " - ipv6: Fix a potential NPD in cleanup_prefix_route()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53217", " - net: mvpp2: sync RX data at the hardware packet offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53218", " - netfilter: nft_exthdr: fix register tracking for F_PRESENT flag", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52942", " - netfilter: nf_log: validate MAC header was set before dumping it", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53219", " - netfilter: x_tables: avoid leaking percpu counter pointers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53349", " - netfilter: nf_conntrack: destroy stale expectfn expectations on", " unregister", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52939", " - net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic", " completion", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53223", " - net: guard timestamp cmsgs to real error queue skbs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53227", " - net: openvswitch: fix possible kfree_skb of ERR_PTR", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53230", " - net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52947", " - net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53232", " - net: phy: clean the sfp upstream if phy probing fails", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53236", " - tcp: restrict SO_ATTACH_FILTER to priv users", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53350", " - ASoC: wm_adsp: Fix NULL dereference when removing firmware controls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53237", " - gpio: mvebu: fix NULL pointer dereference in suspend/resume", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53238", " - netlabel: validate unlabeled address and mask attribute lengths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53239", " - xfrm: policy: fix use-after-free on inexact bin in", " xfrm_policy_bysel_ctx()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46320", " - tap: free page on error paths in tap_get_user_xdp()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53242", " - ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked", " streams", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53352", " - signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53245", " - net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63870", " - ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53249", " - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53252", " - Bluetooth: fix memory leak in error path of hci_alloc_dev()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53253", " - Bluetooth: bnep: reject short frames before parsing", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53254", " - Bluetooth: RFCOMM: validate skb length in MCC handlers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53255", " - Bluetooth: MGMT: validate advertising TLV before type checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53256", " - Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63868", " - net: garp: fix unsigned integer underflow in garp_pdu_parse_attr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53353", " - hsr: Remove WARN_ONCE() in hsr_addr_is_self().", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53263", " - 6lowpan: fix off-by-one in multicast context address compression", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53264", " - net/sched: act_api: use RCU with deferred freeing for action lifecycle", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53265", " - dm cache policy smq: check allocation under invalidate lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53266", " - netfilter: bridge: make ebt_snat ARP rewrite writable", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53267", " - netfilter: nft_ct: bail out on template ct in get eval", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53268", " - netfilter: conntrack_irc: fix possible out-of-bounds read", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53269", " - netfilter: synproxy: add mutex to guard hook reference counting", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53270", " - ipvs: clear the svc scheduler ptr early on edit", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53273", " - tee: optee: prevent use-after-free when the client exits before the", " supplicant", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53274", " - net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53275", " - ipv6: mcast: Fix use-after-free when processing MLD queries", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52948", " - i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63898", " - USB: serial: mct_u232: fix memory corruption with small endpoint", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52910", " - bpf: Free reuseport cBPF prog after RCU grace period.", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43311", " - soc/tegra: pmc: Fix unsafe generic_handle_irq() call", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43240", " - x86/kexec: add a sanity check on previous kernel's ima kexec buffer", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-23346", " - arm64: io: Extract user memory type in ioremap_prot()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52944", " - ksmbd: fix FSCTL permission bypass by adding a permission check for", " FSCTL_SET_SPARSE", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64006", " - netfilter: nf_tables: fix dst corruption in same register operation", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547)", " - Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size", " - drm/v3d: Fix use-after-free of CPU job query arrays on error path", " - drm/v3d: Release indirect CSD GEM reference on CPU job free", " - xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit", " - net/sched: sch_sfb: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - bcache: fix uninitialized closure object", " - nfc: llcp: Fix use-after-free in llcp_sock_release()", " - nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()", " - xfrm: Check for underflow in xfrm_state_mtu", " - nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems", " - kunit: fix use-after-free in debugfs when using kunit.filter", " - netfilter: xt_cpu: prefer raw_smp_processor_id", " - vsock: keep poll shutdown state consistent", " - net: netlink: fix sending unassigned nsid after assigned one", " - net: netlink: don't set nsid on local notifications", " - net/smc: Do not re-initialize smc hashtables", " - net/iucv: fix locking in .getsockopt", " - scsi: core: Run queues for all non-SDEV_DEL devices from", " scsi_run_host_queues", " - ipv4: free net->ipv4.sysctl_local_reserved_ports after", " unregister_net_sysctl_table()", " - ALSA: pcm: oss: Fix setup list UAF on proc write error", " - ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors", " - gpio: mxc: fix irq_high handling", " - ethtool: rss: fix hkey leak when indir_size is 0", " - ASoC: codecs: simple-mux: Fix enum control bounds check", " - Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()", " - bonding: refuse to enslave CAN devices", " - ethtool: eeprom: add missing ethnl_ops_begin() / _complete() during", " fallback", " - ethtool: eeprom: add more safeties to EEPROM Netlink fallback", " - net/sched: Revert \"net/sched: Restrict conditions for adding duplicating", " netems to qdisc tree\"", " - net/handshake: Use spin_lock_bh for hn_lock", " - nvme-tcp: store negative errno in queue->tls_err", " - net/handshake: Pass negative errno through handshake_complete()", " - Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success", " - Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp", " - Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close", " - gpio: rockchip: convert bank->clk to devm_clk_get_enabled()", " - net: mana: Add NULL guards in teardown path to prevent panic on attach", " failure", " - sctp: fix race between sctp_wait_for_connect and peeloff", " - ipv6: fix possible infinite loop in rt6_fill_node()", " - ipv6: fix possible infinite loop in fib6_select_path()", " - net: skbuff: fix pskb_carve leaking zcopy pages", " - perf: Fix dangling cgroup pointer in cpuctx", " - batman-adv: tvlv: abort OGM send on tvlv append failure", " - batman-adv: tt: reject oversized local TVLV buffers", " - batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface", " - batman-adv: iv: recover OGM scheduling after forward packet error", " - batman-adv: tp_meter: avoid role confusion in tp_list", " - batman-adv: tp_meter: directly shut down timer on cleanup", " - batman-adv: tt: avoid empty VLAN responses", " - batman-adv: bla: avoid double decrement of bla.num_requests", " - media: rc: fix race between unregister and urb/irq callbacks", " - media: rc: ttusbir: fix inverted error logic", " - inet: frags: add inet_frag_queue_flush()", " - HID: core: Add printk_ratelimited variants to hid_warn() etc", " - drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register", " - drm/i915/psr: Read Intel DPCD workaround register", " - drm/dp: Add eDP 1.5 bit definition", " - drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used", " - phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X", " - batman-adv: tt: prevent TVLV entry number overflow", " - iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer", " - usb: typec: ucsi: ccg: reject firmware images without a ':' record", " header", " - usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload", " VDO", " - usb: typec: altmodes/displayport: validate count before reading Status", " Update VDO", " - usb: typec: wcove: don't write past struct pd_message in", " wcove_read_rx_buffer()", " - usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT", " - usb: typec: ucsi: validate connector number in ucsi_connector_change()", " - USB: serial: safe_serial: fix memory corruption with small endpoint", " - media: rc: igorplugusb: fix control request setup packet", " - Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free()", " - HID: quirks: Add ALWAYS_POLL quirk for SIGMACHIP USB mouse", " - Bluetooth: btusb: Allow firmware re-download when version matches", " - hpfs: fix a crash if hpfs_map_dnode_bitmap fails", " - auxdisplay: line-display: fix OOB read on zero-length message_store()", " - Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn", " - Bluetooth: HIDP: fix missing length checks in hidp_input_report()", " - Bluetooth: ISO: fix UAF in iso_recv_frame", " - Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock", " - Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync", " - Input: xpad - fix out-of-bounds access for Share button", " - parport: Fix race between port and client registration", " - USB: cdc-acm: Fix bit overlap and move quirk definitions to header", " - KVM: arm64: PMU: Preserve AArch32 counter low bits", " - KVM: SVM: Flush the current TLB when transitioning from xAVIC => x2AVIC", " - iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux", " - iio: adc: npcm: fix unbalanced clk_disable_unprepare()", " - iio: dac: max5821: fix return value check in powerdown sync", " - iio: dac: ad5686: fix input raw value check", " - iio: dac: ad5686: acquire lock when doing powerdown control", " - iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw", " - iio: gyro: itg3200: fix i2c read into the wrong stack location", " - iio: gyro: adis16260: fix division by zero in write_raw", " - iio: ssp_sensors: cancel delayed work_refresh on remove", " - iio: temperature: tsys01: fix broken PROM checksum validation", " - iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL", " - iio: light: cm3323: fix reg_conf not being initialized correctly", " - iio: buffer: hw-consumer: fix use-after-free in error path", " - USB: serial: omninet: fix memory corruption with small endpoint", " - usb: cdns3: gadget: fix request skipping after clearing halt", " - usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy", " acquisition failure", " - usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently", " leaks the runtime PM usage counter across bind/unbind cycles", " - usb: dwc2: Fix use after free in debug code", " - Input: elan_i2c - validate firmware size before use", " - wireguard: send: append trailer after expanding head", " - bpf: sockmap: fix tail fragment offset in bpf_msg_push_data", " - macsec: fix replay protection at XPN lower-PN wrap", " - ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params", " - ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().", " - ipv6: validate extension header length before copying to cmsg", " - xfrm: input: hold netns during deferred transport reinjection", " - ip6: vti: Use ip6_tnl.net in vti6_changelink().", " - HID: wacom: Fix OOB write in wacom_hid_set_device_mode()", " - iommu, debugobjects: avoid gcc-16.1 section mismatch warnings", " - nfc: hci: fix out-of-bounds read in HCP header parsing", " - xfrm: route MIGRATE notifications to caller's netns", " - xfrm: ah: use skb_to_full_sk in async output callbacks", " - ALSA: scarlett2: Fix 2i2 Gen 4 direct monitor gain on firmware 2417", " - netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without", " direction check", " - ASoC: qcom: q6asm-dai: close stream only when running", " - ASoC: qcom: q6asm-dai: do not set stream state in event and trigger", " callbacks", " - Input: xpad - add \"Nova 2 Lite\" from GameSir", " - Input: xpad - add support for ASUS ROG RAIKIRI II", " - ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops", " - Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem", " - Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490", " - comedi: comedi_test: fix check for valid scan_begin_src in", " waveform_ai_cmdtest()", " - comedi: comedi_test: Fix limiting of convert_arg in", " waveform_ai_cmdtest()", " - counter: Fix refcount leak in counter_alloc() error path", " - tty: serial: pch_uart: add check for dma_alloc_coherent()", " - usb: chipidea: core: convert ci_role_switch to local variable", " - usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval", " - USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub", " controllers", " - usb: storage: Add quirks for PNY Elite Portable SSD", " - usbip: vudc: Fix use after free bug in vudc_remove due to race condition", " - usb: usbtmc: check URB actual_length for interrupt-IN notifications", " - usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize", " - USB: serial: option: add MeiG SRM813Q", " - USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL", " - USB: serial: belkin_sa: validate interrupt status length", " - USB: serial: cypress_m8: validate interrupt packet headers", " - USB: serial: keyspan: fix missing indat transfer sanity check", " - USB: serial: mxuport: fix memory corruption with small endpoint", " - USB: serial: mct_u232: fix missing interrupt-in transfer sanity check", " - usb: gadget: uvc: hold opts->lock across XU walks in uvc_function_bind", " - usb: gadget: net2280: Fix double free in probe error path", " - usb: gadget: f_hid: fix device reference leak in hidg_alloc()", " - usb: gadget: composite: fix integer underflow in WebUSB GET_URL handling", " - usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports", " - usb: gadget: f_fs: copy only received bytes on short ep0 read", " - thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()", " - thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow", " - scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker", " - scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32", " - drm/hyperv: validate resolution_count and fix WIN8 fallback", " - drm/hyperv: validate VMBus packet size in receive callback", " - drm/i915: Fix potential UAF in TTM object purge", " - drm/amd/pm/si: Disregard vblank time when no displays are connected", " - serial: altera_jtaguart: handle uart_add_one_port() failures", " - serial: qcom-geni: fix UART_RX_PAR_EN bit position", " - serial: sh-sci: fix memory region release in error path", " - serial: zs: Fix swapped RI/DSR modem line transition counting", " - serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma", " - drm/amdkfd: fix NULL pointer bug in svm_range_set_attr", " - drm/amdkfd: fix a vulnerability of integer overflow in kfd debugger", " - drm/amdkfd: Check for pdd drm file first in CRIU restore path", " - serial: dz: Fix bootconsole message clobbering at chip reset", " - serial: dz: Fix bootconsole handover lockup", " - serial: dz: Convert to use a platform device", " - serial: zs: Fix bootconsole handover lockup", " - serial: zs: Switch to using channel reset", " - serial: zs: Convert to use a platform device", " - USB: serial: cypress_m8: fix memory corruption with small endpoint", " - USB: serial: digi_acceleport: fix memory corruption with small endpoints", " - xhci: tegra: Fix ghost USB device on dual-role port unplug", " - iommu: Skip PASID validation for devices without PASID capability", " - x86/boot: Disable stack protector for early boot code", " - rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg", " - rxrpc: Fix RESPONSE packet verification to extract skb to a linear", " buffer", " - serdev: Provide a bustype shutdown function", " - Bluetooth: hci_qca: Migrate to serdev specific shutdown function", " - Bluetooth: hci_qca: Convert timeout from jiffies to ms", " - ALSA: scarlett2: Return ENOSPC for out-of-bounds flash writes", " - ALSA: scarlett2: Allow flash writes ending at segment boundary", " - mm/memory: fix spurious warning when unmapping device-private/exclusive", " pages", " - platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery", " - net: hsr: defer node table free until after RCU readers", " - mptcp: pm: fix ADD_ADDR timer infinite retry on option space", " insufficient", " - ice: fix VF queue configuration with low MTU values", " - mptcp: cleanup fallback dummy mapping generation", " - mptcp: reset rcv wnd on disconnect", " - arm64: tlb: Flush walk cache when unsharing PMD tables", " - octeontx2-pf: avoid double free of pool->stack on AQ init failure", " - mptcp: introduce the mptcp_init_skb helper", " - mptcp: handle first subflow closing consistently", " - mptcp: do not drop partial packets", " - mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()", " - iio: chemical: scd30: Use guard(mutex) to allow early returns", " - iio: chemical: scd30: fix division by zero in write_raw", " - iio: dac: ad5686: fix ref bit initialization for single-channel parts", " - ALSA: firewire-motu: Protect register DSP event queue positions", " - usb: dwc3: xilinx: fix error handling in zynqmp init error paths", " - usb: musb: omap2430: Fix use-after-free in omap2430_probe()", " - usb: typec: ucsi: Check if power role change actually happened before", " handling", " - thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()", " - usb: typec: ucsi: Don't update power_supply on power role change if not", " connected", " - hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with", " pmbus_lock", " - hwmon: (pmbus/adm1266) serialize NVMEM blackbox read with pmbus_lock", " - hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock", " - mm: perform all memfd seal checks in a single place", " - mm/memfd: fix spelling and grammatical issues", " - memfd: deny writeable mappings when implying SEAL_WRITE", " - usb: core: Fix SuperSpeed root hub wMaxPacketSize", " - Upstream stable to v6.12.93", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43331", " - x86/kexec: Disable KCOV instrumentation after load_segments()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52943", " - net: skbuff: fix missing zerocopy reference in pskb_carve helpers", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53358", " - Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52923", " - ipc: limit next_id allocation to the valid ID range", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2025-68768", " - inet: frags: flush pending skbs in fqdir_pre_exit()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43303", " - mm/page_alloc: clear page->private in free_pages_prepare()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52934", " - batman-adv: tvlv: reject oversized TVLV packets", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52913", " - batman-adv: v: stop OGMv2 on disabled interface", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46322", " - tun: free page on build_skb failure in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46321", " - tun: free page on short-frame rejection in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52927", " - netfilter: ebtables: fix OOB read in compat_mtw_from_user", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43219", " - net: cpsw_new: Fix potential unregister of netdev that has not been", " registered yet", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-45930", " - net: mctp: ensure our nlmsg responses are initialised", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53080", " - net/sched: cls_fw: fix NULL dereference of \"old\" filters before change()", "", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Enable CONFIG_ARM64_ERRATUM_4118414", "", " * CVE-2025-10263", " - arm64: cputype: Add C1-Ultra definitions", " - arm64: cputype: Add C1-Premium definitions", "", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", "", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", "", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", "", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", "", " * CVE-2026-63886", " - scsi: target: iscsi: Validate CHAP_R length before base64 decode", "", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", "", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", "", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", "", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", "", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", "", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", "", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", "", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", "", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", "", " * CVE-2026-64000", " - net: hsr: fix potential OOB access in supervision frame handling", "", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", "", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", "", " * CVE-2026-53131", " - netfilter: require Ethernet MAC header before using eth_hdr()", "" ], "package": "linux", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:47:58 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-147.147", "" ], "package": "linux-meta", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 12:33:08 +0200" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-146.146", "" ], "package": "linux-meta", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:48:49 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-145.145", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.8.0-145.145", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Tue, 01 Sep 2026 22:49:50 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-141.141", "" ], "package": "linux-meta", "version": "6.8.0-141.141", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Edoardo Canepa ", "date": "Sat, 29 Aug 2026 11:37:32 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "open-iscsi", "from_version": { "source_package_name": "open-iscsi", "source_package_version": "2.1.9-3ubuntu5.4", "version": "2.1.9-3ubuntu5.4" }, "to_version": { "source_package_name": "open-iscsi", "source_package_version": "2.1.9-3ubuntu5.5", "version": "2.1.9-3ubuntu5.5" }, "cves": [], "launchpad_bugs_fixed": [ 2147499 ], "changes": [ { "cves": [], "log": [ "", " * d/extra/initramfs/local-top/iscsi: normalize static bootproto for", " initramfs netplan conversion. In iscsi_auto flow, firmware reports", " bootproto as STATIC, but netinfo_to_netplan handles static IPv4", " through PROTO=none with address fields. Map STATIC to PROTO=none", " and record IPV4PROTO=static in net-*.conf. (LP: #2147499)", "" ], "package": "open-iscsi", "version": "2.1.9-3ubuntu5.5", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2147499 ], "author": "Zhang Hua ", "date": "Fri, 03 Jul 2026 17:01:52 +0800" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-client", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.19", "version": "1:9.6p1-3ubuntu13.19" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.20", "version": "1:9.6p1-3ubuntu13.20" }, "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: sftp directory traversal", " - debian/patches/CVE-2026-106552-pre1.patch: upstream: similar to scp, fix", " implicit destination path selection in sftp.c.", " - debian/patches/CVE-2026-106552.patch: upstream: sftp: be stricter in", " accepting paths returned by the in sftp-client.c, sftp.c.", " - CVE-2026-106552", " * SECURITY UPDATE: incorrect GSSAPIAuthentication auth persistence", " - debian/patches/CVE-2026-106553-1.patch: upstream: Reset GSSAPI client", " state before authentication in auth2.c, gss-serv.c, monitor.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-2.patch: upstream: Only store GSSAPI creds", " when authn succeeds in gss-serv.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-3.patch: upstream:", " ssh_gssapi_cleanup_global_client() needs a prototype in gss-serv.c, ssh-", " gss.h.", " - CVE-2026-106553", " - CVE-2026-106555", " * SECURITY UPDATE: incorrect use of LZ77 dictionary coder", " - debian/patches/CVE-2026-106582.patch: upstream: Disable LZ77 dictionary", " coder to avoid a potential in packet.c.", " - CVE-2026-106582", " * SECURITY UPDATE: invalid chars in command-line username", " - debian/patches/CVE-2026-106583-1.patch: upstream: Further restrict the", " characters allowed in a command-line in readconf.c.", " - debian/patches/CVE-2026-106583-2.patch: upstream: Add test for", " proxycommand percent expansions. in regress/percent.sh.", " - debian/patches/CVE-2026-106583-3.patch: avoid ksh-ism in regress test in", " regress/percent.sh.", " - CVE-2026-106583", " * SECURITY UPDATE: incorrect cert expiry in ssh-keygen", " - debian/patches/CVE-2026-106584.patch: upstream: Correct handling of DST", " when converting dates in misc.c.", " - CVE-2026-106584", " * SECURITY UPDATE: missing maximum packet length check", " - debian/patches/CVE-2026-106585.patch: upstream: Check that compressed", " payloads don't inflate beyond the in packet.c.", " - CVE-2026-106585", " * SECURITY UPDATE: incorrect restrict keyword usage in tunnel forwarding", " - debian/patches/CVE-2026-106586-1.patch: upstream: Propagate", " authorized_keys \"resrict\" keyword in auth-options.c.", " - debian/patches/CVE-2026-106586-2.patch: upstream: correctly check", " sshauthopt->restricted merging in regress/unittests/authopt/tests.c.", " - debian/patches/CVE-2026-106586-3.patch: upstream: simpler in", " regress/unittests/authopt/tests.c.", " - CVE-2026-106586", " * SECURITY UPDATE: \"none\" value confusion in options", " - debian/patches/CVE-2026-106587.patch: upstream: Correctly handle some", " options that accept \"none\" in servconf.c.", " - CVE-2026-106587", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.20", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 08 Oct 2026 13:19:18 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.19", "version": "1:9.6p1-3ubuntu13.19" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.20", "version": "1:9.6p1-3ubuntu13.20" }, "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: sftp directory traversal", " - debian/patches/CVE-2026-106552-pre1.patch: upstream: similar to scp, fix", " implicit destination path selection in sftp.c.", " - debian/patches/CVE-2026-106552.patch: upstream: sftp: be stricter in", " accepting paths returned by the in sftp-client.c, sftp.c.", " - CVE-2026-106552", " * SECURITY UPDATE: incorrect GSSAPIAuthentication auth persistence", " - debian/patches/CVE-2026-106553-1.patch: upstream: Reset GSSAPI client", " state before authentication in auth2.c, gss-serv.c, monitor.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-2.patch: upstream: Only store GSSAPI creds", " when authn succeeds in gss-serv.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-3.patch: upstream:", " ssh_gssapi_cleanup_global_client() needs a prototype in gss-serv.c, ssh-", " gss.h.", " - CVE-2026-106553", " - CVE-2026-106555", " * SECURITY UPDATE: incorrect use of LZ77 dictionary coder", " - debian/patches/CVE-2026-106582.patch: upstream: Disable LZ77 dictionary", " coder to avoid a potential in packet.c.", " - CVE-2026-106582", " * SECURITY UPDATE: invalid chars in command-line username", " - debian/patches/CVE-2026-106583-1.patch: upstream: Further restrict the", " characters allowed in a command-line in readconf.c.", " - debian/patches/CVE-2026-106583-2.patch: upstream: Add test for", " proxycommand percent expansions. in regress/percent.sh.", " - debian/patches/CVE-2026-106583-3.patch: avoid ksh-ism in regress test in", " regress/percent.sh.", " - CVE-2026-106583", " * SECURITY UPDATE: incorrect cert expiry in ssh-keygen", " - debian/patches/CVE-2026-106584.patch: upstream: Correct handling of DST", " when converting dates in misc.c.", " - CVE-2026-106584", " * SECURITY UPDATE: missing maximum packet length check", " - debian/patches/CVE-2026-106585.patch: upstream: Check that compressed", " payloads don't inflate beyond the in packet.c.", " - CVE-2026-106585", " * SECURITY UPDATE: incorrect restrict keyword usage in tunnel forwarding", " - debian/patches/CVE-2026-106586-1.patch: upstream: Propagate", " authorized_keys \"resrict\" keyword in auth-options.c.", " - debian/patches/CVE-2026-106586-2.patch: upstream: correctly check", " sshauthopt->restricted merging in regress/unittests/authopt/tests.c.", " - debian/patches/CVE-2026-106586-3.patch: upstream: simpler in", " regress/unittests/authopt/tests.c.", " - CVE-2026-106586", " * SECURITY UPDATE: \"none\" value confusion in options", " - debian/patches/CVE-2026-106587.patch: upstream: Correctly handle some", " options that accept \"none\" in servconf.c.", " - CVE-2026-106587", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.20", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 08 Oct 2026 13:19:18 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-sftp-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.19", "version": "1:9.6p1-3ubuntu13.19" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.20", "version": "1:9.6p1-3ubuntu13.20" }, "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: sftp directory traversal", " - debian/patches/CVE-2026-106552-pre1.patch: upstream: similar to scp, fix", " implicit destination path selection in sftp.c.", " - debian/patches/CVE-2026-106552.patch: upstream: sftp: be stricter in", " accepting paths returned by the in sftp-client.c, sftp.c.", " - CVE-2026-106552", " * SECURITY UPDATE: incorrect GSSAPIAuthentication auth persistence", " - debian/patches/CVE-2026-106553-1.patch: upstream: Reset GSSAPI client", " state before authentication in auth2.c, gss-serv.c, monitor.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-2.patch: upstream: Only store GSSAPI creds", " when authn succeeds in gss-serv.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-3.patch: upstream:", " ssh_gssapi_cleanup_global_client() needs a prototype in gss-serv.c, ssh-", " gss.h.", " - CVE-2026-106553", " - CVE-2026-106555", " * SECURITY UPDATE: incorrect use of LZ77 dictionary coder", " - debian/patches/CVE-2026-106582.patch: upstream: Disable LZ77 dictionary", " coder to avoid a potential in packet.c.", " - CVE-2026-106582", " * SECURITY UPDATE: invalid chars in command-line username", " - debian/patches/CVE-2026-106583-1.patch: upstream: Further restrict the", " characters allowed in a command-line in readconf.c.", " - debian/patches/CVE-2026-106583-2.patch: upstream: Add test for", " proxycommand percent expansions. in regress/percent.sh.", " - debian/patches/CVE-2026-106583-3.patch: avoid ksh-ism in regress test in", " regress/percent.sh.", " - CVE-2026-106583", " * SECURITY UPDATE: incorrect cert expiry in ssh-keygen", " - debian/patches/CVE-2026-106584.patch: upstream: Correct handling of DST", " when converting dates in misc.c.", " - CVE-2026-106584", " * SECURITY UPDATE: missing maximum packet length check", " - debian/patches/CVE-2026-106585.patch: upstream: Check that compressed", " payloads don't inflate beyond the in packet.c.", " - CVE-2026-106585", " * SECURITY UPDATE: incorrect restrict keyword usage in tunnel forwarding", " - debian/patches/CVE-2026-106586-1.patch: upstream: Propagate", " authorized_keys \"resrict\" keyword in auth-options.c.", " - debian/patches/CVE-2026-106586-2.patch: upstream: correctly check", " sshauthopt->restricted merging in regress/unittests/authopt/tests.c.", " - debian/patches/CVE-2026-106586-3.patch: upstream: simpler in", " regress/unittests/authopt/tests.c.", " - CVE-2026-106586", " * SECURITY UPDATE: \"none\" value confusion in options", " - debian/patches/CVE-2026-106587.patch: upstream: Correctly handle some", " options that accept \"none\" in servconf.c.", " - CVE-2026-106587", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.20", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 08 Oct 2026 13:19:18 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssl", "from_version": { "source_package_name": "openssl", "source_package_version": "3.0.13-0ubuntu3.15", "version": "3.0.13-0ubuntu3.15" }, "to_version": { "source_package_name": "openssl", "source_package_version": "3.0.13-0ubuntu3.16", "version": "3.0.13-0ubuntu3.16" }, "cves": [ { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-35189", "url": "https://ubuntu.com/security/CVE-2026-35189", "cve_description": "Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix postpones processing of the CRL distribution points extensions in certificates to the time when the processed value is required for CRL processing. This avoids keeping large memory allocations for a long time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-54872", "url": "https://ubuntu.com/security/CVE-2026-54872", "cve_description": "Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing. Impact summary: An attacker able to measure signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very small; observing it requires a large number of measurements. The effect is largest for curves whose group order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use the affected code path.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75805", "url": "https://ubuntu.com/security/CVE-2026-75805", "cve_description": "Issue summary: A CMP client that requests certificate revocation on the basis of a PKCS#10 CSR may dereference a NULL pointer and terminate abnormally when processing a crafted revocation response. Impact summary: The NULL pointer dereference happens on a read which leads to a crash and a Denial of Service for the affected client application. CWE: CWE-476: NULL-pointer dereference Description: A CMP client revoking a certificate has to tell the server which certificate to revoke, and may do so by supplying a PKCS#10 CSR instead of the certificate itself or its issuer name and serial number. This is 'openssl cmp -cmd rr -csr ' on the command line, or OSSL_CMP_exec_RR_ses() with the certificate supplied via OSSL_CMP_CTX_set1_p10CSR() through the API. A CSR does not contain the issuer name and serial number of the certificate, so the client does not send them. A server may optionally name the certificate it revoked in its response, and the client then compares that name against what it sent. Having sent neither an issuer name nor a serial number, it has nothing to compare against, and a server returning a specially crafted name causes the client to read from a NULL pointer and crash. The revocation response is checked for valid message protection before the affected code is reached, so an attacker must be a malicious or compromised CMP server, or a man-in-the-middle in possession of the secret used for message protection. Clients that identify the certificate to be revoked by a certificate or by issuer and serial number rather than by a PKCS#10 CSR are not affected. FIPS impact: no No FIPS modules are affected by this issue, as the CMP protocol implementation is outside the OpenSSL FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-75806", "url": "https://ubuntu.com/security/CVE-2026-75806", "cve_description": "Issue summary: An established DTLS 1.2 association using an AEAD cipher suite can be terminated by a single unauthenticated datagram whose encrypted fragment is shorter than the mandatory explicit IV and authentication tag overhead. Impact summary: An attacker who can send a datagram that is routed to an existing DTLS 1.2 association can tear that association down without knowing any key material. This is a Denial of Service limited to the targeted association. There is no memory safety or confidentiality impact. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD cipher suite carries an explicit IV followed by the ciphertext and an authentication tag. When decrypting such a record the record layer passed the record length to the cipher implementation before checking that the record was long enough to contain the explicit IV and the tag. For a record shorter than that overhead the cipher implementation rejected the impossible length, and the record layer treated this as an internal failure and raised a fatal internal_error alert instead of treating the record as one that failed authentication. In TLS 1.2 the same record causes a fatal internal_error alert instead of the expected bad_record_mac alert. Since any undecryptable record already terminates a TLS connection, this is a protocol conformance issue rather than a security issue in TLS. The fix validates the record length against the explicit IV and tag length before any AEAD processing, so that TLS reports bad_record_mac and DTLS silently discards the record. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-77696", "url": "https://ubuntu.com/security/CVE-2026-77696", "cve_description": "Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel. Impact summary: An attacker able to measure SM2 signing times may learn information about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy Description: SM2 signature generation computes the signature value using variable-time BIGNUM operations on the secret nonce and the private key, so the time taken to produce an SM2 signature depends on these secret values, forming a timing side-channel. Applications performing SM2 signature generation are affected on all platforms. FIPS Impact: no SM2 is not a FIPS algorithm.", "cve_priority": "low", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-84782", "url": "https://ubuntu.com/security/CVE-2026-84782", "cve_description": "Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly. Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue. The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build. The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code is outside the FIPS module boundary.", "cve_priority": "high", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Excessive Memory Allocation in Relative CRLDP Processing", " - debian/patches/CVE-2026-35189.patch: Defer computation of relative CRLDP", " names in crypto/x509/v3_crld.c, crypto/x509/v3_purp.c,", " crypto/x509/x509_vfy.c, include/crypto/x509.h.", " - CVE-2026-35189", " * SECURITY UPDATE: Timing Side-Channel in Scalar Multiplication for Non-NIST", " EC Curves", " - debian/patches/CVE-2026-54872-pre1.patch: add value_barrier_bn() to", " include/internal/constant_time.h.", " - debian/patches/CVE-2026-54872.patch: ec: make ossl_ec_scalar_mul_ladder()", " scalar padding constant time in crypto/bn/bn_intern.c,", " crypto/ec/ec_mult.c, include/crypto/bn.h.", " - CVE-2026-54872", " * SECURITY UPDATE: NULL Pointer Dereference in CMP Client Revocation Response", " Handling", " - debian/patches/CVE-2026-75805-1.patch: Guard comparison when values are", " NULL in crypto/cmp/cmp_client.c.", " - debian/patches/CVE-2026-75805-2.patch: Add test for CVE-2026-75805 in", " test/cmp_client_test.c.", " - CVE-2026-75805", " * SECURITY UPDATE: Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes", " DoS", " - debian/patches/CVE-2026-75806.patch: TLS: Reject undersized TLS 1.2 AEAD", " records before AEAD processing in ssl/record/record.h,", " ssl/record/ssl3_record.c, ssl/t1_enc.c, test/recordlentest.c.", " - CVE-2026-75806", " * SECURITY UPDATE: Timing Side-Channel in SM2 Signature Generation", " - debian/patches/CVE-2026-77696.patch: sm2: make sm2_sig_gen() constant time", " in crypto/ec/ec_mult.c, crypto/sm2/sm2_sign.c.", " - CVE-2026-77696", " * SECURITY UPDATE: DTLS Retransmits Handshake Messages From a Stale Buffer", " Offset", " - debian/patches/CVE-2026-84782.patch: dtls: reset init_off before", " retransmitting a message in ssl/d1_lib.c, ssl/statem/statem_dtls.c,", " test/dtlstest.c.", " - CVE-2026-84782", "" ], "package": "openssl", "version": "3.0.13-0ubuntu3.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 16 Sep 2026 14:47:02 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-jwt", "from_version": { "source_package_name": "pyjwt", "source_package_version": "2.7.0-1ubuntu0.1", "version": "2.7.0-1ubuntu0.1" }, "to_version": { "source_package_name": "pyjwt", "source_package_version": "2.7.0-1ubuntu0.3", "version": "2.7.0-1ubuntu0.3" }, "cves": [ { "cve": "CVE-2026-102267", "url": "https://ubuntu.com/security/CVE-2026-102267", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. This occurs when a configured trusted JWKS endpoint returns an attacker-influenced redirect. As a result, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102268", "url": "https://ubuntu.com/security/CVE-2026-102268", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102271", "url": "https://ubuntu.com/security/CVE-2026-102271", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102272", "url": "https://ubuntu.com/security/CVE-2026-102272", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.prepare_key in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102273", "url": "https://ubuntu.com/security/CVE-2026-102273", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because HMAC key guard only recognizes top-level public JWK forms and misses container representations. This occurs when an application allows HMAC and asymmetric algorithms and passes a public JWK container as the raw key. As a result, public asymmetric key material is accepted as the HMAC secret. Consequently, an attacker who knows the public key can forge a token with arbitrary authenticated claims. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-48522", "url": "https://ubuntu.com/security/CVE-2026-48522", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained \"plant a JWKS to forge tokens\" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48524", "url": "https://ubuntu.com/security/CVE-2026-48524", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient.get_signing_key() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48525", "url": "https://ubuntu.com/security/CVE-2026-48525", "cve_description": "PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (\"b64\": false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48526", "url": "https://ubuntu.com/security/CVE-2026-48526", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-102267", "url": "https://ubuntu.com/security/CVE-2026-102267", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. This occurs when a configured trusted JWKS endpoint returns an attacker-influenced redirect. As a result, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102268", "url": "https://ubuntu.com/security/CVE-2026-102268", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102271", "url": "https://ubuntu.com/security/CVE-2026-102271", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102272", "url": "https://ubuntu.com/security/CVE-2026-102272", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.prepare_key in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102273", "url": "https://ubuntu.com/security/CVE-2026-102273", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because HMAC key guard only recognizes top-level public JWK forms and misses container representations. This occurs when an application allows HMAC and asymmetric algorithms and passes a public JWK container as the raw key. As a result, public asymmetric key material is accepted as the HMAC secret. Consequently, an attacker who knows the public key can forge a token with arbitrary authenticated claims. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Unvalidated HTTP redirect traversal in PyJWKClient", " - debian/patches/CVE-2026-102267.patch: Reject redirects in PyJWKClient", " fetches in jwt/jwks_client.py, tests/test_jwks_client.py.", " - CVE-2026-102267", " * SECURITY UPDATE: Algorithm confusion via whitespace and line-break evasion", " in is_pem_format", " - debian/patches/CVE-2026-102268.patch: fix: reject loader-accepted PEM", " variants in jwt/utils.py, tests/test_algorithms.py.", " - CVE-2026-102268", " * SECURITY UPDATE: Algorithm confusion via DER-encoded public key bytes in ", " HMACAlgorithm.prepare_key", " - debian/patches/CVE-2026-102271.patch: fix: reject DER public keys as ", " HMAC secrets in jwt/algorithms.py, tests/test_algorithms.py.", " - CVE-2026-102271", " * SECURITY UPDATE: Key inspection bypass via UTF-8 Byte Order Mark (BOM) in", " HMACAlgorithm.prepare_key", " - debian/patches/CVE-2026-102272.patch: Reject encoded JWKs as HMAC keys", " in jwt/algorithms.py, tests/test_algorithms.py.", " - CVE-2026-102272", " * SECURITY UPDATE: Key-type spoofing via nested JWK container structures in ", " HMACAlgorithm.prepare_key", " - debian/patches/CVE-2026-102273.patch: fix: reject public JWK container", " HMAC keys in jwt/algorithms.py, tests/test_algorithms.py.", " - CVE-2026-102273", "" ], "package": "pyjwt", "version": "2.7.0-1ubuntu0.3", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Hurman ", "date": "Thu, 08 Oct 2026 15:21:26 +0800" }, { "cves": [ { "cve": "CVE-2026-48522", "url": "https://ubuntu.com/security/CVE-2026-48522", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained \"plant a JWKS to forge tokens\" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48524", "url": "https://ubuntu.com/security/CVE-2026-48524", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient.get_signing_key() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48525", "url": "https://ubuntu.com/security/CVE-2026-48525", "cve_description": "PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (\"b64\": false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" }, { "cve": "CVE-2026-48526", "url": "https://ubuntu.com/security/CVE-2026-48526", "cve_description": "PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.", "cve_priority": "medium", "cve_public_date": "2026-05-28 16:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: multiple security vulnerabilities", " - debian/patches/CVE-2026-48522-to-48526.patch: Bundle security fixes and", " hardening into 2.13.0 in jwt/algorithms.py, jwt/api_jws.py,", " jwt/jwks_client.py, tests/test_algorithms.py, tests/test_api_jws.py,", " tests/test_jwks_client.py.", " - CVE-2026-48522", " - CVE-2026-48524", " - CVE-2026-48525", " - CVE-2026-48526", "" ], "package": "pyjwt", "version": "2.7.0-1ubuntu0.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Shishir Subedi ", "date": "Mon, 21 Sep 2026 13:39:20 +0545" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-requests", "from_version": { "source_package_name": "requests", "source_package_version": "2.31.0+dfsg-1ubuntu1.1", "version": "2.31.0+dfsg-1ubuntu1.1" }, "to_version": { "source_package_name": "requests", "source_package_version": "2.31.0+dfsg-1ubuntu1.2", "version": "2.31.0+dfsg-1ubuntu1.2" }, "cves": [ { "cve": "CVE-2026-25645", "url": "https://ubuntu.com/security/CVE-2026-25645", "cve_description": "Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.", "cve_priority": "low", "cve_public_date": "2026-03-25 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-25645", "url": "https://ubuntu.com/security/CVE-2026-25645", "cve_description": "Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.", "cve_priority": "low", "cve_public_date": "2026-03-25 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Insecure Temporary File", " - debian/patches/CVE-2026-25645.patch: Extract to non-deterministic", " location", " - CVE-2026-25645", "" ], "package": "requests", "version": "2.31.0+dfsg-1ubuntu1.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Wed, 23 Sep 2026 13:12:59 +1000" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-urllib3", "from_version": { "source_package_name": "python-urllib3", "source_package_version": "2.0.7-1ubuntu0.7", "version": "2.0.7-1ubuntu0.7" }, "to_version": { "source_package_name": "python-urllib3", "source_package_version": "2.0.7-1ubuntu0.8", "version": "2.0.7-1ubuntu0.8" }, "cves": [ { "cve": "CVE-2026-97688", "url": "https://ubuntu.com/security/CVE-2026-97688", "cve_description": "urllib3 is an HTTP client library for Python. From 2.6.2 until 2.8.0, HTTPResponse.stream and HTTPResponse.read_chunked can enter an infinite loop because the Deflate decoder retains trailing bytes as unconsumed input after reaching end-of-stream and repeatedly decodes them without progress. The issue occurs when an untrusted server sends a chunked Deflate response whose decoded body exceeds a positive finite chunk size and whose encoded body has trailing bytes, specifically a response with Transfer-Encoding: chunked and Content-Encoding: deflate, content decoding enabled, and the positive finite amt=N streaming chunk size. The attack mechanism is that a malicious server returns a compressed chunked response with trailing bytes after the Deflate stream. The impact is excessive CPU usage and a request that does not complete, and network read timeouts do not interrupt the loop because no further socket read occurs. This issue is fixed in version 2.8.0.", "cve_priority": "medium", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-97689", "url": "https://ubuntu.com/security/CVE-2026-97689", "cve_description": "urllib3 is an HTTP client library for Python. From 1.10.3 until 2.8.0, the HTTPResponse.read_chunked and HTTPResponse.stream methods can allocate unbounded memory because the streaming chunk parser buffers the chunk-size field until newline or EOF without a length bound. The trigger is that a malicious server returns Transfer-Encoding: chunked followed by a very long run of bytes without a newline. The attack mechanism is that a malicious HTTP server sends a very long unterminated chunk-size line. The impact is that unbounded memory allocation can exhaust the client process. This issue is fixed in version 2.8.0.", "cve_priority": "medium", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-97688", "url": "https://ubuntu.com/security/CVE-2026-97688", "cve_description": "urllib3 is an HTTP client library for Python. From 2.6.2 until 2.8.0, HTTPResponse.stream and HTTPResponse.read_chunked can enter an infinite loop because the Deflate decoder retains trailing bytes as unconsumed input after reaching end-of-stream and repeatedly decodes them without progress. The issue occurs when an untrusted server sends a chunked Deflate response whose decoded body exceeds a positive finite chunk size and whose encoded body has trailing bytes, specifically a response with Transfer-Encoding: chunked and Content-Encoding: deflate, content decoding enabled, and the positive finite amt=N streaming chunk size. The attack mechanism is that a malicious server returns a compressed chunked response with trailing bytes after the Deflate stream. The impact is excessive CPU usage and a request that does not complete, and network read timeouts do not interrupt the loop because no further socket read occurs. This issue is fixed in version 2.8.0.", "cve_priority": "medium", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-97689", "url": "https://ubuntu.com/security/CVE-2026-97689", "cve_description": "urllib3 is an HTTP client library for Python. From 1.10.3 until 2.8.0, the HTTPResponse.read_chunked and HTTPResponse.stream methods can allocate unbounded memory because the streaming chunk parser buffers the chunk-size field until newline or EOF without a length bound. The trigger is that a malicious server returns Transfer-Encoding: chunked followed by a very long run of bytes without a newline. The attack mechanism is that a malicious HTTP server sends a very long unterminated chunk-size line. The impact is that unbounded memory allocation can exhaust the client process. This issue is fixed in version 2.8.0.", "cve_priority": "medium", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-97688.patch: Prevent an infinite loop", " when decoding Deflate responses", " - debian/patches/CVE-2026-97689.patch: Bound chunk-size line reads", " to prevent memory exhaustion DoS", " - CVE-2026-97688", " - CVE-2026-97689", "" ], "package": "python-urllib3", "version": "2.0.7-1ubuntu0.8", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 13 Oct 2026 13:55:12 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "sg3-utils", "from_version": { "source_package_name": "sg3-utils", "source_package_version": "1.46-3ubuntu4", "version": "1.46-3ubuntu4" }, "to_version": { "source_package_name": "sg3-utils", "source_package_version": "1.46-3ubuntu4.1", "version": "1.46-3ubuntu4.1" }, "cves": [ { "cve": "CVE-2026-16313", "url": "https://ubuntu.com/security/CVE-2026-16313", "cve_description": "A flaw was found in sg3_utils. The sg_inq command, when invoked with the --export option, outputs device identification data without sanitizing control characters in SCSI name string fields. A newline character embedded in a device-supplied name string can inject arbitrary properties into the udev device database. This could allow an attacker who can present a crafted SCSI device to execute arbitrary commands as root when the device is disconnected.", "cve_priority": "medium", "cve_public_date": "2026-07-28 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-16313", "url": "https://ubuntu.com/security/CVE-2026-16313", "cve_description": "A flaw was found in sg3_utils. The sg_inq command, when invoked with the --export option, outputs device identification data without sanitizing control characters in SCSI name string fields. A newline character embedded in a device-supplied name string can inject arbitrary properties into the udev device database. This could allow an attacker who can present a crafted SCSI device to execute arbitrary commands as root when the device is disconnected.", "cve_priority": "medium", "cve_public_date": "2026-07-28 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: command injection via udev property injection", " - debian/patches/CVE-2026-16313.patch: apply udev-conforming character", " encoding to the VPD 0x83 SCSI name string and T10 vendor ID ATA", " subfield output of sg_inq --export, so a crafted SCSI device cannot", " inject udev properties and execute commands as root (fix released", " upstream in sg3_utils 1.49).", " - debian/patches/CVE-2026-16313_2.patch: avoid including 0-bytes in SCSI", " name strings (upstream follow-up fix).", " - CVE-2026-16313", "" ], "package": "sg3-utils", "version": "1.46-3ubuntu4.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Allen Huang ", "date": "Thu, 01 Oct 2026 14:12:14 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "sg3-utils-udev", "from_version": { "source_package_name": "sg3-utils", "source_package_version": "1.46-3ubuntu4", "version": "1.46-3ubuntu4" }, "to_version": { "source_package_name": "sg3-utils", "source_package_version": "1.46-3ubuntu4.1", "version": "1.46-3ubuntu4.1" }, "cves": [ { "cve": "CVE-2026-16313", "url": "https://ubuntu.com/security/CVE-2026-16313", "cve_description": "A flaw was found in sg3_utils. The sg_inq command, when invoked with the --export option, outputs device identification data without sanitizing control characters in SCSI name string fields. A newline character embedded in a device-supplied name string can inject arbitrary properties into the udev device database. This could allow an attacker who can present a crafted SCSI device to execute arbitrary commands as root when the device is disconnected.", "cve_priority": "medium", "cve_public_date": "2026-07-28 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-16313", "url": "https://ubuntu.com/security/CVE-2026-16313", "cve_description": "A flaw was found in sg3_utils. The sg_inq command, when invoked with the --export option, outputs device identification data without sanitizing control characters in SCSI name string fields. A newline character embedded in a device-supplied name string can inject arbitrary properties into the udev device database. This could allow an attacker who can present a crafted SCSI device to execute arbitrary commands as root when the device is disconnected.", "cve_priority": "medium", "cve_public_date": "2026-07-28 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: command injection via udev property injection", " - debian/patches/CVE-2026-16313.patch: apply udev-conforming character", " encoding to the VPD 0x83 SCSI name string and T10 vendor ID ATA", " subfield output of sg_inq --export, so a crafted SCSI device cannot", " inject udev properties and execute commands as root (fix released", " upstream in sg3_utils 1.49).", " - debian/patches/CVE-2026-16313_2.patch: avoid including 0-bytes in SCSI", " name strings (upstream follow-up fix).", " - CVE-2026-16313", "" ], "package": "sg3-utils", "version": "1.46-3ubuntu4.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Allen Huang ", "date": "Thu, 01 Oct 2026 14:12:14 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "snapd", "from_version": { "source_package_name": "snapd", "source_package_version": "2.76.3+ubuntu24.04", "version": "2.76.3+ubuntu24.04" }, "to_version": { "source_package_name": "snapd", "source_package_version": "2.77.1+ubuntu24.04", "version": "2.77.1+ubuntu24.04" }, "cves": [ { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" }, { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2158102, 2072331, 2110510, 2143934, 2160691, 2161982, 2158301, 2159940, 2157692, 2067006, 2157692, 2067006, 2154498, 2147606, 2148544, 2139213, 2125344, 2150683, 2152908, 1966067, 2110368, 2110368, 2144666, 2146337, 2147207, 2143882 ], "changes": [ { "cves": [], "log": [ "", " * New upstream release, LP: #2158102", " - Fix undo of unlink-component after its snap revision was discarded", " - interfaces: power-control | allow reading all battery state files", "" ], "package": "snapd", "version": "2.77.1+ubuntu24.04", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2158102 ], "author": "Ernest Lotter ", "date": "Wed, 02 Sep 2026 14:39:12 +0200" }, { "cves": [], "log": [ "", " - Account for differences in names of the binaries in the snapd FIPS", " build", " - Add code to calculate canonical subject name hash", " - Add commands for debugging or accessing snap mount namespaces", " - Add helpers for listing and iterating device mediation groups", " - Add package ebpf with helpers wrapping eBPF exposed objects with", " dependency on github.com/cilium/ebpf", " - Add secondary prerequisites task that acts as the synchronization", " point, which ensures that a snap's prerequisites are available", " before it's installed", " - Add support for shell conditional syntax in envs", " - Added /usr/share/{man,help,info} to system-packages-doc", " - asserts: add validation-sets confdb-schema builtin", " - asserts: ensure that compatibility labels are strings", " - asserts: extend on-classic constraints to accept \"distro/variant\",", " \"distro/*\", and \"distro/\" under a new snap-declaration format 7", " - asserts: validate serial in newDeviceIDFromString", " - Bump github.com/canonical/go-efilib to v1.8.0 to include fixes for", " efivars probe", " - confdb: add validation-sets handler and fix data loss when writing", " to new schemas or accounts", " - confdb: fix bug on reading uneven lists", " - confdb: literal subkeys are sorted after placeholders", " - confdb: run observe-view-* hooks after commit", " - confdb: support Encode/Decode for builtins", " - confdb: support sign-only external keypair backends", " - core-initrd: add missing libbpf and systemd dlopen dependencies,", " and increase mount burst", " - Drop task logs for delayed effects", " - During snap removal, clear-snap task errors early if there are", " user mounts in snap data dirs", " - Enable reverts to trigger a seed refresh", " - Ensure profiles are setup before running prepare-{slot, plug}*", " hooks", " - Ensure that prereqs created by initial refresh run before create-", " recovery-system", " - Exclude Georgian from translation linting", " - experimental features: graduate layouts, classic-preserves-xdg-", " runtime-dir, refresh-app-awareness, and dbus-activation features", " - experimental features: warn when setting graduated or default-", " enabled experimental features and do not store settings for", " graduated features", " - Expose individual certs as well as c_rehash emulation", " - Extend autogen with explicit --sysconfdir", " - External keypair manager: add shared external key manager", " implementation", " - External keypair manager: refactor GPG and external keypair", " managers to use extKeypairMgrImpl", " - External keypair manager: support external OPENPGP signing in", " ExternalKeypairManager", " - FDE: add post install actions API", " - FDE: add reprovision API", " - FDE: add reprovision recovery key generation API", " - FDE: add reseal check after snapd refresh", " - FDE: allow reprovision without factory reset", " - FDE: change makebootable part of the boot package to not take", " install observers as parameters", " - FDE: extend storage-encrypted system information", " - FDE: make reprovision only seal", " - FDE: remove all tmp keyslots on error", " - FDE: remove check for unchanged authentication options", " - FDE: run post install checks during auto repair", " - Filter seed-refresh based on model and seed presence", " - Fix failing snap remove when there are snapctl created mounts", " under snap global data dirs", " - Fix postNotices to validate before locking state", " - Guard the ensure check from running on classic", " - Implement remodeling fully in terms of updates", " - Implement ShutDown for HookManager", " - Include variables SNAP_APP_NAME, and when applicable", " SNAP_APP_COMMON_ID, SNAP_APP_DESKTOP_FILE and SNAP_APP_BUS_NAME in", " snap application environments", " - interfaces: add xdg-portal-permission-store interface", " - interfaces: allow gtk css in subdirectories", " - interfaces: allow systemd networkd link property changes via D-Bus", " - interfaces: allow the systemd networkctl command", " - interfaces: allow Wine to execute files accessed via the Document", " Portal", " - interfaces: apparmor-observe | add interface", " - interfaces: attempt to fix content with parallel installs", " - interfaces: devlxd | fix access for LXD containers", " - interfaces: docker | allow connecting to system-wide docker on", " classic", " - interfaces: grant default access to memory.high in a snap's cgroup", " - interfaces: iscsi-initiator | allow access to /var/lib/iscsi/nodes", " - interfaces: kernel-sched-ext-control | add the kernel sched-ext", " control interface implementation", " - interfaces: make polkit and upower implicit on Core systems only", " - interfaces: open-iscsi | add missing state paths", " - interfaces: opengl | expose wsl libraries", " - interfaces: u2f-devices | add atkey PID and relative VID support", " - List dir contents on failure to remove snap base data dir", " - List non-snapctl mounts in snap data dirs", " - LP: #2072331 Validate map keys in JSON config values", " - LP: #2110510 Interfaces: allow reading of /proc/self/smaps_rollup", " - LP: #2143934 Interfaces: network-control, network-manager | allow", " missing resolve1 link setters", " - LP: #2160691 Security logging: strip trailing whitespace from", " audit netlink message payload", " - LP: #2161982 Interfaces: vsock | add interface for VM guest", " services", " - Make arguments of debug mount-namespace consistent with other", " debug commands", " - Make bootloader logging less verbose", " - Make cert manager garbage check run after symlink migration", " - Make secondary prerequisite synchronization task handle same-", " change retries", " - mkversion.sh: do describe in worktrees too", " - multi-entry snapd: merge snap and snapd binaries", " - multi-entry snapd: move debug device-cgroup implementation file", " under cmd/snapd/cli", " - multi-entry snapd: move snap-gpio-helper sources around before", " transitioning to multi-entry dispatch", " - multi-entry snapd: move snapd-apparmor sources to a dedicated tool", " location", " - multi-entry snapd: move source files around in preparation for", " snapd/snap merge", " - multi-entry snapd: move the snap-preseed sources around in", " preparation", " - multi-entry snapd: move the sources of snapctl and snap-exec in", " preparation for the multi-entry dispatch", " - Never create seed refresh tasks during a remodel", " - packaging: assign a default label for /tmp/snap-private-tmp and", " set it during installation", " - packaging: build deb with Go 1.23 for noble and jammy, Go 1.22 for", " focal", " - packaging: drop SNAP_TAGS", " - packaging: drop symlinks for opensuse 15.5/15.6 packaging", " - packaging: fix service startup during install and session-agent", " socket handling on Ubuntu 26.04+", " - packaging: fix stderr redirection", " - packaging: restore gbp.conf output directory for Ubuntu 26.04", " builds", " - packaging: switch to apparmor 5.x with 5 ABI", " - packaging: update bundled AppArmor to 5.0.2 and accept the 5.0 ABI", " when running as deb", " - packaging: use a relative symlink for snapctl and update steam-", " support udev rules", " - Preserve component in hook security tags", " - Prevent removal of seed-refresh snaps when seed-refresh is enabled", " - Refactor base-declaration into 1st class builtin assertion", " - Refactor how the is-originating-from-snap-command advisory check", " works", " - Refactor prerequisites task handler to enable proper seed-refresh", " integration", " - Reintroduce fdstore helpers", " - remote device management: add task to validate request messages", " - remote device management: apply management messages, queue", " response messages, and improve sequencing and redelivery handling", " - Remove osutil unused AtomicWriteFollow flag", " - Remove xerrors dependency", " - Reuse existing seed-refresh implementation for free during single-", " path installation", " - Rework how SnapSetup.SnapPath is used", " - seccomp: allow rseq_slice_yield", " - security logging: add seclog API for administrative actions and", " token create/remove events", " - security logging: add security logging for adding, updating and", " removing a snapd user", " - Set target hostname from install-mode", " - snap-confine: improve loading of BPF programs, retry on failures", " to collect verifier logs", " - snap-confine: use profile and flags= in snap-confine and snap-", " update-ns' AppArmor profiles", " - snap-confine: work around kernel mnt_ns_loop() ordering bug on", " 6.18.x", " - snap: add debug command for listing currently mediated devices for", " a given snap", " - snap: fix self-managed cgroup support checks", " - snap: report hidden file access for paths allowed by home when", " prompting is active", " - snap: report read-only file access for paths allowed by system-", " package-doc", " - snapctl async support: add --format json to snap tasks to be", " consistent with snapctl", " - snapctl async support: add snapctl tasks command", " - snapctl async support: async feature negotiation between snap", " client and daemon", " - snapctl async support: fix snapctl is-ready exit codes", " - snapctl async support: re-enable snapctl async functionality", " - snapshots: restore preserves snapctl created mounts", " - snapshots: save excludes all mount points", " - Support ca-certificate.crt only systems like core26", " - Turn on quota-groups by default", " - Use 0755 for certificate generation directories", " - Use CreateTemp for NewAtomicFile tmp file creation", " - Verify cached downloads in the do path and detect obvious", " corruption", "" ], "package": "snapd", "version": "2.77+ubuntu24.04", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2072331, 2110510, 2143934, 2160691, 2161982 ], "author": "Sergio Cazzolato ", "date": "Fri, 24 Jul 2026 20:45:05 -0300" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2158301", " - FDE: support keyboard configuration at install-time for first-boot", " - FDE: re-enable passphrases/PINs at install-time", " - FDE: require volumes authentication if HWROT is missing", " - FDE: bump secboot to rev 457b03a16d19", " - FDE: use new secboot API for reprovision TPM", " - Cross-distro: modify SELinux policy to use", " init_named_socket_activation() for allowing systemd to start snapd", " through socket activation", " - packaging: make sure that usr/bin/snap is built with correct build", " tags on debian sid", " - Ensure profiles are setup before running prepare-{slot, plug}*", " hooks", "" ], "package": "snapd", "version": "2.76.3", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2158301 ], "author": "Katie May ", "date": "Tue, 07 Jul 2026 10:06:48 +0200" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2159940", " - interfaces: steam-support, docker-support | fix mountinfo denial", "" ], "package": "snapd", "version": "2.76.2", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2159940 ], "author": "Katie May ", "date": "Tue, 07 Jul 2026 08:38:51 +0200" }, { "cves": [ { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" } ], "log": [ "", " * New upstream release, LP: #2157692", " - LP: #2067006 CVE-2024-5300", " - CVE-2026-3888", "" ], "package": "snapd", "version": "2.76.1", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2157692, 2067006 ], "author": "Ernest Lotter ", "date": "Thu, 25 Jun 2026 13:09:05 +0200" }, { "cves": [ { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" } ], "log": [ "", " * New upstream release, LP: #2157692", " - LP: #2067006 CVE-2024-5300", " - CVE-2026-3888", " - SNAPDENG-36017", "" ], "package": "snapd", "version": "2.76.1", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2157692, 2067006 ], "author": "Ernest Lotter ", "date": "Sat, 20 Jun 2026 10:27:54 +0200" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2154498", " - assertions: add helper for validating integrity data", " - assertions: drop incorrect/non-standard Ed25519 support", " - confdb: allow only API admin read access to confdb secrets", " - confdb: block concurrent confdb accesses", " - confdb: block concurrent snapctl accesses to configuration", " database", " - confdb: check for ephemeral data when missing save-view hook on", " commit", " - confdb: ignore not-found errors in confdb-schema refreshes", " - confdb: support --wait-for timeouts when accessing confdb", " - core-initrd: add group referenced in udev rules", " - core-initrd: add libbpf dependency to initramfs", " - core-initrd: add missing libbpf dependency in 24.04 packaging", " - core-initrd: ensure audio is a system group", " - core-initrd: fix /boot/uboot mount with u-boot env in dedicated", " partition", " - core-initrd: increase mount burst from 5 to 128 for faster boot", " - core-initrd: sync partition udev rules with the ones in core-base", " - core-initrd: sync with latest upload to snappy-dev PPA", " - core-initrd: synchronize changelogs with latest PPA upload", " - core-initrd: update changelog with latest PPA upload", " - core-initrd: add nfnetlink module to fix nf netlink", " socket speed regression (Ubuntu Core only)", " - cross-distro: allow snapd to manipulate systemd unit files in", " SELinux policy", " - cross-distro: FIPS bootstrap and dispatch via snap-fips-dispatch", " - desktop: fix common ID selection with multiple desktop plugs", " - FDE: allow user mode on core in secboot TPM handling", " - FDE: bump go-efilib dependency", " - FDE: bump secboot to rev cdcb64992e54 for FDE fixes", " - FDE: deprecate check-pin/passphrase API endpoints", " - LP: #2147606 FDE: give inactive state on classic", " - FDE: improve tracing for OP-TEE probing", " - FDE: move auto-repair logic to overlord/fdestate and provide state", " - FDE: update secboot for TPM/FDE bug fixes including Intel HAP and", " recovery key parsing", " - FDE: use any primary key matching digest when adding a keyslot", " - FDE: use ignore action for preinstall check in VM", " - interfaces: bluez | drop explicit deny send_destination in D-Bus", " configuration", " - interfaces: conditionally deny /proc/self/mountinfo to suppress Go", " 1.25+ denials", " - interfaces: custom-device | fix for-device validation panic on", " non-string value", " - interfaces: disallow auto-connect to parallel installs", " - interfaces: docker | make plug implicit on classic systems", " - interfaces: ignore errors in disconnect hooks during explicit snap", " disconnect", " - interfaces: mediatek-accel | add plug interface base declaration", " - interfaces: microceph-support | suppress noisy sudo denial audit", " logs", " - interfaces: podman | add new interface for podman socket access", " - interfaces: pulseaudio | fix security tag syntax inconsistency", " - interfaces: raw-usb | allow USB device enumeration on Fairphone 5", " with NexDock", " - interfaces: restore auto-connections on failed refresh undo", " - LP: #2148544 interfaces: bool-file | support deep SoC sysfs paths", " for LED brightness", " - LP: #2139213 packaging: make Ubuntu 16.04 packaging dep17", " compliant", " - packaging: add cross-distro build script and instructions", " - packaging: add openSUSE 16.0 spread support", " - packaging: Debian build improvements", " - packaging: default openSUSE to /var/lib/snapd/snap and sync from", " downstream", " - packaging: drop transitional packages only for Ubuntu 26.04", " (Resolute)", " - packaging: fix Launchpad FIPS build detection for snapd-fips job", " - packaging: refactor and clean up snapd.mk, standardize test-data", " directories", " - packaging: switch to golang-github-chai2010-gettext-go-dev", " - packaging: update bundled AppArmor 4.1.7 (snapd snap only)", " - prompting: escape paths in prompt constraints", " - prompting: improve API error handling and validation", " - prompting: improve error message when no handler service is", " present", " - prompting: re-enable the prompting notice backend", " - prompting: respond with full user-allowed permission set", " - prompting: validate permissions while unmarshalling", " - remote device management: implement dispatch-mgmt-messages task", " with sequencing support", " - LP: #2125344 snap: avoid empty channel forwarding message", " - LP: #2150683 snap: clarify snap install help text for --classic", " and --devmode", " - LP: #2152908 snap: print complex attributes in snap interface", " --attrs output", " - snap: add run-inhibit hint and inhibit info when a snap is", " disabled", " - snap: allow removing a snap and its base at the same time", " - snap: display detailed component information in snap info", " - snap: extend AlreadyInstalledError to multiple snaps and", " components", " - snap: extend set-quota command options description with accepted", " value formats", " - snap: implement snap delta command for computing snap deltas", " - snap: improve consistency for snap install when some snaps are", " already installed", " - snap: show hint in snap list that a snap has components", " - snap-confine: allow inheriting unix sockets from snaps", " - snap-confine: allow linking to libm in AppArmor profile", " - snap-confine: fix out-of-bounds read in mountinfo parser for", " partial escape sequences", " - snap-confine: harden bpffs mount with nosuid, nodev, noexec flags", " - snap-confine: remove experimental persistent per-user mount", " namespace feature", " - snap-confine: set FD_CLOEXEC on file descriptors returned by BPF", " helpers", " - snap-confine: support transparent_hugepage in AppArmor profile", " - snap-confine: use strchr after NUL-terminating in infofile parser", " - snap-update-ns: switch to a multi-pass process for constructing", " and updating mount namespaces", " - RemoveMountUnitFile now unmounts even if mount unit file is", " missing", " - Add explicit mount phase during single-reboot refresh to fix undo", " of kernel refreshes", " - Add security audit logging subsystem", " - Add base prioritized AppArmmor snippets for strictly confined or", " jailed snaps", " - Allow openshell snap to use experimental daemon-scope: user", " - Allow configuring mount unit options based on filesystem type", " - Allow equals signs in uevent values in netlink parser", " - Also bind-mount directories modified by kmod backend during", " preseed", " - Clean up potentially corrupted files during snap download undo", " - Complete the bootloader environment implementation", " - Copy integrity data files during snap install", " - Create hook for seed refresh mode", " - Create removal tasks for old seed-refresh seeds", " - Dispatch systemctl commands asynchronously when calling Stop()", " - Ensure /tmp/.X11-unix created inside mount namespace has correct", " permissions", " - Ensure exclusive changes conflict with refresh/revert", " - Ensure existing snap confinement flags are not dropped when", " installing or removing components", " - Export ubuntu-boot-state filename constant from bootloader package", " - Fix duplicate removal of apps under $SNAP_MOUNT_DIR/bin", " - Fix integration between prerequisites task and seed-refresh mode", " - Fix split-refresh overwriting provided lane", " - Fix use of umask in GetListener for socket activation", " - Ignore net.ErrClosed during daemon shutdown", " - Implement ResolveValidationSetsEnforcementError in terms of one", " call", " - Improve snapctl install consistency when components are already", " installed", " - Inject seed creation tasks into snap refresh flow", " - Introduce system options for custom certificates on Ubuntu Core", " - Keep idle services with activation units stopped on reload", " - List snap components in snap-debug-info via debug-tools", " - Look at gadget.yaml instead of marker file to determine ubootpart", " usage", " - LP: #1966067 Skip redundant xdg-settings confirmation prompt when", " setting is already correct", " - LP: #2110368 Fix component installation for private snaps via", " snapctl", " - LP: #2110368 Fix download of private snap components by setting", " UserID", " - LP: #2144666 Fix mount namespace updates with synthetic bind", " mounts on same target paths", " - LP: #2146337 Improve handling of failed downloads and retain", " partial files for resume", " - LP: #2147207 Fix snap enable/disable cycle forgetting components", " - Make run-inhibit hint for kill-snap-apps task based on kill reason", " - Merge content-provider prerequisite updates into seed-refresh", " - Move SortServices into Backend.StartServices", " - Move state to client change conversion to ctlcmd package", " - Omit misleading \"try to refresh snapd\" suggestion for ISA-related", " errors", " - Only create link-component tasks when needed during refresh to", " existing revision", " - Reconfigure piboot bootloader on gadget refreshes to preserve", " os_prefix", " - Reduce the number of AppArmor profile regenerations during snap", " operations", " - Refactor seed-refresh ownership to devicestate", " - Regenerate certificate database on remodels", " - Remove obsolete FIXME comment in VersionCompare", " - Remove unused GenerateDmVerityData helper from snap/integrity", " - Rename and document error type for ISA assumes flags", " - Restart snapd from daemon.Stop to improve restart reliability", " - Restart stopped services on error in stopSnapServices for", " transactionality", " - Simplify certificate-db updates on model-base refresh/installs", " - Support racing Loop and Stop correctly in overlord", " - Support sending file descriptors to systemd via sd_notify", " - Unroll CPU-heavy recursive function in snap state handlers", " - Update seccomp syscalls list for kernel 7.1.0", " - Use change ID to prevent nested seed-refresh spawned by", " prerequisites", " - Validate content interface plug target directories exist for", " core26+ snaps", " - Validate layout paths exist in snap tree for snaps using bare or", " core26+", "" ], "package": "snapd", "version": "2.76", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2154498, 2147606, 2148544, 2139213, 2125344, 2150683, 2152908, 1966067, 2110368, 2110368, 2144666, 2146337, 2147207 ], "author": "Ernest Lotter ", "date": "Thu, 28 May 2026 20:00:16 +0200" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2143882", " - Interfaces: network-setup-*| allow running python binaries from", " the base on UC26+", " - Cross-distro: modify SELinux policy to allow mounting on", " /var/snap//", " - Fix potential task deadlock by considering all tasks in a lane", " that might be waiting for a reboot when processing delayed", " security backend effects", "" ], "package": "snapd", "version": "2.75.2", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2143882 ], "author": "Katie May ", "date": "Mon, 30 Mar 2026 17:06:36 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "sosreport", "from_version": { "source_package_name": "sosreport", "source_package_version": "4.10.2-0ubuntu0~24.04.1", "version": "4.10.2-0ubuntu0~24.04.1" }, "to_version": { "source_package_name": "sosreport", "source_package_version": "4.11.2-0ubuntu0~24.04.1", "version": "4.11.2-0ubuntu0~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2156921 ], "changes": [ { "cves": [], "log": [ "", " * New 4.11.2 upstream release. (LP: #2156921)", "", " * For more details, full release note is available here:", " - https://github.com/sosreport/sos/releases/tag/4.11.2", "", " * d/control:", " - Update Vcs-Browser and Vcs-Git to reflect the Salsa repository migration", " to Debian Python Team", " - Add xz-utils to Depends", "", " *d/copyright: Aligned copyright with Debian", "" ], "package": "sosreport", "version": "4.11.2-0ubuntu0~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2156921 ], "author": "Dan Emmons ", "date": "Fri, 26 Jun 2026 17:15:02 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "sudo", "from_version": { "source_package_name": "sudo", "source_package_version": "1.9.15p5-3ubuntu5.24.04.3", "version": "1.9.15p5-3ubuntu5.24.04.3" }, "to_version": { "source_package_name": "sudo", "source_package_version": "1.9.15p5-3ubuntu5.24.04.4", "version": "1.9.15p5-3ubuntu5.24.04.4" }, "cves": [ { "cve": "CVE-2026-96512", "url": "https://ubuntu.com/security/CVE-2026-96512", "cve_description": "A flaw was found in sudo. When sudoers rules use NOTBEFORE or NOTAFTER time-based access restrictions with timestamps that omit the trailing 'Z' timezone indicator, the time evaluation relies on the TZ environment variable inherited from the calling user. Because sudo is a setuid-root program, an unprivileged local user can set TZ to an extreme timezone offset to shift the authorization window by up to approximately 25 hours, causing expired rules to be treated as valid. This allows the user to execute commands outside the intended time window. Authentication is not bypassed; only the time-based authorization check is affected.", "cve_priority": "medium", "cve_public_date": "2026-09-23 14:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-96512", "url": "https://ubuntu.com/security/CVE-2026-96512", "cve_description": "A flaw was found in sudo. When sudoers rules use NOTBEFORE or NOTAFTER time-based access restrictions with timestamps that omit the trailing 'Z' timezone indicator, the time evaluation relies on the TZ environment variable inherited from the calling user. Because sudo is a setuid-root program, an unprivileged local user can set TZ to an extreme timezone offset to shift the authorization window by up to approximately 25 hours, causing expired rules to be treated as valid. This allows the user to execute commands outside the intended time window. Authentication is not bypassed; only the time-based authorization check is affected.", "cve_priority": "medium", "cve_public_date": "2026-09-23 14:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: NOTBEFORE or NOTAFTER restrictions bypass via TZ", " - debian/patches/CVE-2026-96512-pre1.patch: sudo: ignore user-specified TZ", " environment variable in src/sudo.c.", " - debian/patches/CVE-2026-96512.patch: Remove TZ from sudo's working", " environment without modifying envp. in src/sudo.c.", " - CVE-2026-96512", "" ], "package": "sudo", "version": "1.9.15p5-3ubuntu5.24.04.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 06 Oct 2026 09:51:33 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "systemd", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "systemd-dev", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "systemd-resolved", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "systemd-sysv", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "systemd-timesyncd", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "tzdata", "from_version": { "source_package_name": "tzdata", "source_package_version": "2026c-0ubuntu0.24.04.1", "version": "2026c-0ubuntu0.24.04.1" }, "to_version": { "source_package_name": "tzdata", "source_package_version": "2026e-0ubuntu0.24.04.1", "version": "2026e-0ubuntu0.24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2169125 ], "changes": [ { "cves": [], "log": [ "", " * New upstream release (LP: #2169125):", " - Canada’s Northwest Territories moved to permanent -06 on 2026-08-21 and", " will not fall back from -06 to -07 on 2026-11-01", " - Manitoba moves to permanent -05 on 2026-10-31 and will not fall back", " from -05 to -06 on 2026-11-01", " * Add autopkgtest test cases for 2026d and 2026e releases", " * Revert POSIX conformance of old SysV names EST5EDT, CST6CDT, MST7MDT and", " PST8PDT", " * Update the ICU timezone data to 2026e", " * Add autopkgtest test case for ICU timezone data 2026d and 2026e", "" ], "package": "tzdata", "version": "2026e-0ubuntu0.24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2169125 ], "author": "Benjamin Drung ", "date": "Mon, 05 Oct 2026 11:20:05 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "udev", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-6.8.0-147", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-147.147 -proposed tracker (LP: #2168142)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026)", " - platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug", " - selftests/bpf: Add tests for ld_{abs,ind} failure path in subprogs", " - drm/virtio: fix deadlock in display_info_cb by removing hotplug from", " dequeue worker", " - mtd: mtdswap: remove debugfs stats file on teardown", " - seqlock: Cure some more scoped_seqlock() optimization fails", " - seqlock: Allow KASAN to fail optimizing", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/umem: Add support for creating pinned DMABUF umem with a given dma", " device", " - RDMA/umem: Introduce an option to revoke DMABUF umem", " - RDMA/umem: Add ib_umem_dmabuf_get_pinned_and_lock helper", " - RDMA/umem: Move umem dmabuf revoke logic into helper function", " - RDMA/umem: Add pinned revocable dmabuf import interface", " - RDMA/umem: Add helpers for umem dmabuf revoke lock", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - selftests/alsa: Fix memory leak in find_controls error path", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: cs42l43: Correct report for forced microphone jack", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - sched/vtime: Get rid of generic vtime_task_switch() implementation", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - can: j1939: fix lockless local-destination check", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - crypto: rsa-pkcs1pad: Don't WARN on an empty digest", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - wifi: ath11k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - wifi: ath12k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - ASoC: cs35l56: Don't use devres to unregister component", " - ASoC: cs35l56: Fix potential probe() deadlock", " - ASoC: cs35l56: Use complete_all() to signal init_completion", " - wifi: iwlwifi: mvm: validate SAR GEO response payload size", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - hwmon: (asus-ec-sensors) fix looping over banks while reading from EC", " - hwmon: (asus-ec-sensors) fix EC read intervals", " - hwmon: (asus-ec-sensors) add missed handle for ENOMEM", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - pds_core: yield the CPU while waiting for the adminq to drain", " - pds_core: order completion reads after the ownership check", " - pds_core: check for workqueue allocation failure", " - tls: device: push pending open record on splice EOF", " - selftest: af_unix: Add Kconfig file.", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - amt: make the head writable before rewriting the L2 header", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: dpaa: fix mode setting", " - iomap: correct the range of a partial dirty clear", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - net: stmmac: enable the MAC on link up for all supported speeds", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - ppp: use IFF_NO_QUEUE in virtual interfaces", " - ppp: convert to percpu netstats", " - ppp: enable TX scatter-gather", " - ppp: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: fix LAG recipe to profile association", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't", " at 0 (v2)", " - drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nxp: imx8-isi: Clean up already-initialized pipes on probe", " failure", " - media: nxp: imx8-isi: Fix missing v4l2_subdev_cleanup() in pipe init", " error path", " - media: nxp: imx8-isi: Fix scale factor calculation for hardware rounding", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vivid: add vivid_update_reduced_fps()", " - media: vpif_capture: fix OF node reference imbalance", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - LoongArch: Fix oops during single-step debugging", " - x86/boot/compressed: Disable jump tables", " - serial: sc16is7xx: implement gpio get_direction() callback", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - ice: use READ_ONCE() to access cached PHC time", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amd/display: Fix dcn32 DTB DTO update breaking live pixel rate", " sources", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - net: pcs: xpcs: fix SGMII state reading", " - bpf: drop bpf_lsm_getselfattr from hook list", " - udmabuf: Do not create malformed scatterlists", " - i2c: davinci: Unregister cpufreq notifier on probe failure", " - VFS/audit: introduce kern_path_parent() for audit", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - rxrpc: Pull out certain app callback funcs into an ops table", " - fbcon: Rename struct fbcon_ops to struct fbcon_par", " - fbcon: Use correct type for vc_resize() return value", " - rxrpc: Don't need barrier for ->tx_bottom and ->acks_hard_ack", " - rxrpc: Use irq-disabling spinlocks between app and I/O thread", " - rxrpc: Fix notification vs call-release vs recvmsg", " - rxrpc: Fix socket notification race", " - vduse: Use fixed 4KB bounce pages for non-4KB page size", " - vduse: remove unused vaddr parameter of vduse_domain_free_coherent", " - vduse: take out allocations from vduse_dev_alloc_coherent", " - octeontx2: Annotate mmio regions as __iomem", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - fbdev/efifb: Replace references to global screen_info by local pointer", " - ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable()", " - ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe()", " - ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb", " - ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - netfilter: nft_set_pipapo: use GFP_KERNEL for insertions", " - netfilter: nft_set_pipapo: move prove_locking helper around", " - netfilter: nft_set_pipapo: make pipapo_clone helper return NULL", " - netfilter: nft_set_pipapo: prepare walk function for on-demand clone", " - netfilter: nft_set_pipapo: merge deactivate helper into caller", " - netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone", " - netfilter: nft_set_pipapo: move cloning of match info to insert/removal", " path", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_tables: Remove unused nft_reduce_is_readonly()", " - netfilter: nf_tables: remove register tracking infrastructure", " - NFSD: pass nfsd_file to nfsd_iter_read()", " - sunrpc: allocate a separate bvec array for socket sends", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - dma: dw-edma: Fix build warning in dw_edma_pcie_probe()", " - dmaengine: dw-edma: Fix confusing cleanup.h syntax", " - platform/x86: dell-smbios: Move request functions for reuse", " - i2c: imx: separate atomic, dma and non-dma use case", " - nfs: remove dead code for the old swap over NFS implementation", " - ovl: use linked upper dentry in copy-up tmpfile", " - bootconfig: do not put quotes on cmdline items unless necessary", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - rxrpc: Disable IRQ, not BH, to take the lock for ->attend_link", " - netfilter: nft_quota: use atomic64_xchg for reset", " - soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE", " - wifi: cfg80211: pass net_device to .set_monitor_channel", " - wifi: cfg80211: define and use wiphy guard", " - wifi: cfg80211: derive S1G beacon TSF from S1G fields", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - smb: move some duplicate definitions to common/cifsglob.h", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - wifi: mt76: mt7925: extend mt7925_mcu_bss_he_tlv for per-link BSS", " - ovl: fix trusted xattr escape prefix matching", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - dpll: add clock quality level attribute and op", " - net/mlx5: DPLL, Add clock quality level op implementation", " - net/mlx5: Remove newline at the end of a netlink error message", " - net/mlx5: Refactor EEPROM query error handling to return status", " separately", " - octeontx2-pf: tc: fix egress ratelimiting", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm/displayid: move drm_displayid.h to drm_displayd_internal.h", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - ALSA: timer: drain a slave's callback before its master detaches it", " - ALSA: timer: don't re-enter an instance callback that is still running", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - sysctl: treewide: constify ctl_table_header::ctl_table_arg", " - ceph: fix refcount leak in ceph_readdir()", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - net: move skb_gro_receive_list from udp to core", " - net: add pskb_may_pull() to skb_gro_receive_list()", " - vsock/virtio: collapse receive queue under memory pressure", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - xfs: add an explicit owner field to xfs_da_args", " - xfs: factor out xfs_attr3_leaf_init", " - xfs: don't replace the wrong part of the cow fork", " - rxrpc: Fix CPU time starvation in I/O thread", " - ASoC: mediatek: mt8183-afe-pcm: Shorten memif_data table using macros", " - ASoC: mediatek: mt8183-afe-pcm: Support >32 bit DMA addresses", " - tcp: Decrement tcp_md5_needed static branch", " - nvmet: Introduce nvmet_req_transfer_len()", " - block: add helper add_disk_final()", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections", " - Bluetooth: hci_core: Fix not accounting for BIS/CIS/PA links separately", " - afs: Improve server refcount/active count tracing", " - afs: Make afs_lookup_cell() take a trace note", " - afs: Drop the net parameter from afs_unuse_cell()", " - rxrpc: Allow the app to store private data on peer structs", " - afs: Use the per-peer app data provided by rxrpc", " - afs: Fix afs_server ref accounting", " - afs: Simplify cell record handling", " - afs: Fix dynamic lookup to fail on cell lookup failure", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - lib/string_choices: Add str_plural() helper", " - USB: gadget: Use str_enable_disable-like helpers", " - usb: musb: omap2430: clean up probe error handling", " - net/mlx5e: Fix NULL pointer dereference in ioctl module EEPROM query", " - rxrpc: Fix locking issues with the peer record hash", " - wifi: nl80211: fix nl80211_start_radar_detection return value", " - afs: Set vllist to NULL if addr parsing fails", " - dpll: fix clock quality level reporting", " - afs: Fix delayed allocation of a cell's anonymous key", " - afs: handle CB.InitCallBackState3 requests without a server record", " - Bluetooth: hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK", " - Bluetooth: hci_conn: Fix not cleaning up Broadcaster/Broadcast Source", " - Bluetooth: hci_conn: Remove redundant memset after kzalloc", " - Bluetooth: hci_conn: Fix not cleaning up PA_LINK connections", " - Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()", " - afs: Fix uninit var in afs_alloc_anon_key()", " - Upstream stable to v6.6.148, v6.12.101", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72168", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72213", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72244", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53078", " - bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2025-40098", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_get_acpi_mute_state()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68372", " - usb: core: port: Deattach Type-C connector on component unbind", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72175", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45901", " - netfilter: nf_tables: revert commit_mutex usage in reset path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45897", " - netfilter: nft_counter: serialize reset with spinlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72015", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72017", " - net: macb: drop in-flight Tx SKBs on close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72030", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72023", " - octeontx2-pf: fix SQB pointer leak on init failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72040", " - ipmi: fix refcount leak in i_ipmi_request()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72045", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72062", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72051", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72070", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72142", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72147", " - dmaengine: dw-edma-pcie: Reject devices without driver data", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72254", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72253", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72260", " - ASoC: mediatek: mt8192: Check runtime resume during probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72305", " - VDUSE: avoid leaking information to userspace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64205", " - i2c: i801: fix hardware state machine corruption in error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64280", " - fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72146", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72124", " - can: isotp: serialize TX state transitions under so->rx_lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72125", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72115", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72117", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72116", " - can: bcm: fix stale rx/tx ops after device removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72113", " - can: bcm: add missing device refcount for CAN filter removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72114", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72119", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72118", " - can: bcm: fix CAN frame rx/tx statistics", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72121", " - can: bcm: add locking when updating filter and timer values", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53090", " - bpf: Fix ld_{abs,ind} failure path analysis in subprogs", "", " * test_vxlan_vnifiltering.sh from ubuntu_kselftests_net failed on linux-", " oem-6.8 (with ipv6 default rdst) (LP: #2071590)", " - selftests: net: use slowwait to make sure IPv6 setup finished", "", " * ubuntu_bpf failed to build in noble (error: redefinition of", " 'stack_load_preserves_const_precision') (LP: #2160493)", " - SAUCE: Revert \"selftests/bpf: validate fake register spill/fill", " precision backtracking logic\"", "", " * CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", "", " * Backport: \"mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios\"", " (LP: #2162917)", " - mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios", "", " * qrtr: ns: node limit of 64 breaks QRTR routing on large multi-node", " deployments (LP: #2165140)", " - net: qrtr: ns: Raise node count limit to 512", "", " * [UBUNTU 24.04] kernel: CPU hotplug unsupported by CPUMF (LP: #2165732)", " - s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks", "", " * CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", "", " * CVE-2025-38563", " - perf/core: Prevent VMA split of buffer mappings", "", " * CVE-2025-38565", " - perf/core: Exit early on perf_mmap() fail", "", " * CVE-2025-38187", " - drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()", "", " * CVE-2025-38069", " - PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops", "", " * CVE-2025-40014", " - objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()", "", " * CVE-2025-21985", " - drm/amd/display: Fix out-of-bound accesses", "", " * CVE-2024-56552", " - drm/xe/guc_submit: fix race around suspend_pending", "", " * CVE-2025-21687", " - vfio/platform: check the bounds of read/write syscalls", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237)", " - ext4: fix fd leak in EXT4_IOC_MOVE_EXT cross-sb validation", " - mm: refactor mm_access() to not return NULL", " - Upstream stable to v6.6.146, v6.12.98, v6.6.147, v6.12.99, v6.12.100", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237) //", " CVE-2026-64560", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995)", " - bpf, arm64: Reject out-of-range B.cond targets", " - nfsd: release layout stid on setlease failure", " - Bluetooth: btmtk: apply the common btmtk_fw_get_filename", " - Bluetooth: btmtk: Fix failed to send func ctrl for MediaTek devices.", " - Bluetooth: btmtk: Fix wait_on_bit_timeout interruption during shutdown", " - userfaultfd: gate must_wait writability check on pte_present()", " - perf: Fix dangling cgroup pointer in cpuctx backport", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error", " - device property: initialize the remaining fields of fwnode_handle in", " fwnode_init()", " - f2fs: validate orphan inode entry count", " - f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode", " - f2fs: fix potential deadlock in f2fs_balance_fs()", " - f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()", " - f2fs: fix listxattr handling of corrupted xattr entries", " - block: Avoid mounting the bdev pseudo-filesystem in userspace", " - i2c: core: fix irq domain leak on adapter registration failure", " - i2c: core: fix hang on adapter registration failure", " - i2c: core: fix NULL-deref on adapter registration failure", " - i2c: core: fix adapter debugfs creation", " - fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()", " - NFSv4/flexfiles: reject zero filehandle version count", " - locking/rtmutex: Make sure we wake anything on the wake_q when we", " release the lock->wait_lock", " - bonding: fix xfrm offload feature setup on active-backup mode", " - mm/vmscan: flush deferred TLB before freeing large folios", " - perf trace beauty fcntl: Fix build with older kernel headers", " - ACPI: CPPC: Suppress UBSAN warning caused by field misuse", " - ACPI: NFIT: core: Fix possible NULL pointer dereference", " - perf/core: Detach event groups during remove_on_exec", " - arm64: sysreg: Add layout for ID_AA64MMFR4_EL1", " - virtio_net: Support dynamic rss indirection table size", " - LoongArch: Add PIO for early access before ACPI PCI root register", " - usb: gadget: function: rndis: add length check to response query", " - usb: gadget: function: rndis: add length check for header", " - iio: accel: bmc150: clamp the device-reported FIFO frame count", " - iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error", " - iio: adc: lpc32xx: Initialize completion before requesting IRQ", " - iio: adc: ti-ads124s08: Return reset GPIO lookup errors", " - iio: chemical: scd30: Cleanup initializations and fix sign-extension bug", " - iio: event: Fix event FIFO reset race", " - iio: gyro: bmg160: bail out when bandwidth/filter is not in table", " - iio: gyro: bmg160: wait full startup time after mode change at probe", " - iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ", " - iio: imu: st_lsm6dsx: deselect shub page before reading whoami", " - iio: light: al3010: fix incorrect scale for the highest gain range", " - iio: light: gp2ap002: fix runtime PM leak on read error", " - iio: light: opt3001: fix missing state reset on timeout", " - iio: light: tsl2591: return actual error from probe IRQ failure", " - iio: light: veml6030: fix channel type when pushing events", " - iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call", " - iio: temperature: ltc2983: Fix reinit_completion() called after", " conversion start", " - ALSA: virtio: Add missing 384 kHz PCM rate mapping", " - ALSA: ymfpci: check snd_ctl_new1() return value", " - ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input", " parser", " - ALSA: cmipci: check snd_ctl_new1() return value", " - ALSA: es1938: check snd_ctl_new1() return value", " - ALSA: firewire: isight: bound the sample count to the packet payload", " - ALSA: gus: check snd_ctl_new1() return value", " - ALSA: ice1712: check snd_ctl_new1() return value", " - ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()", " - ALSA: usb-audio: avoid kobject path lookup in DualSense match", " - ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()", " - ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch", " put callbacks", " - ALSA: usb-audio: Update Babyface Pro control caches only after", " successful writes", " - ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful", " writes", " - vfio/pci: Use a private flag to prevent power state change with VFs", " - vfio/pci: Latch disable_idle_d3 per device", " - vfio/pci: Release the VGA arbiter client on register_device() failure", " - vfio/pci: Fix racy bitfields and tighten struct layout", " - vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc", " - Bluetooth: btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB", " - Bluetooth: btusb: fix use-after-free on registration failure", " - Bluetooth: btusb: fix use-after-free on marvell probe failure", " - Bluetooth: btusb: fix wakeup source leak on probe failure", " - binder: fix UAF in binder_thread_release()", " - binder: fix UAF in binder_free_transaction()", " - usb: xhci: Fix sleep in atomic context in xhci_free_streams()", " - PCI: altera: Do not dispose parent IRQ mapping", " - mm/damon/ops-common: handle extreme intervals in damon_hot_score()", " - netfilter: ipset: fix race between dump and ip_set_list resize", " - virtio-mmio: fix device release warning on module unload", " - hwrng: virtio: clamp device-reported used.len at copy_data()", " - USB: chaoskey: Fix slab-use-after-free in chaoskey_release()", " - usb: dwc3: run gadget disconnect from sleepable suspend context", " - 6lowpan: fix NHC entry use-after-free on error path", " - tipc: fix out-of-bounds read in broadcast Gap ACK blocks", " - staging: vme_user: bound slave read/write to the kern_buf size", " - smb: client: restrict implied bcc[0] exemption to responses without data", " area", " - staging: vme_user: fix location monitor leak in fake bridge", " - staging: vme_user: fix location monitor leak in tsi148 bridge", " - media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe", " - staging: media: atomisp: reduce load_primary_binaries() stack usage", " - staging: rtl8723bs: fix heap buffer overflow in", " rtw_cfg80211_set_wpa_ie()", " - staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()", " - staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop", " - staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop", " - staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and", " join_cmd_hdl()", " - staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop", " - staging: rtl8723bs: fix OOB write in HT_caps_handler()", " - crypto: amlogic - avoid double cleanup in meson_crypto_probe()", " - ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then", " SMB2_CANCEL", " - net: af_key: initialize alg_key_len for IPComp states", " - audit: Fix data races of skb_queue_len() readers on audit_queue", " - Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete", " - debugobjects: Plug race against a concurrent OOM disable", " - fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns", " - NTB: epf: Avoid calling pci_irq_vector() from hardirq context", " - io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item", " - ipv4: igmp: remove multicast group from hash table on device destruction", " - net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes", " - mfd: cros_ec: Delay dev_set_drvdata() until probe success", " - mm: shrinker: fix NULL pointer dereference in debugfs", " - netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump", " - f2fs: bound i_inline_xattr_size for non-inline-xattr inodes", " - drm/amd: Fix set but not used warnings", " - apparmor: advertise the tcp fast open fix is applied", " - nfsd: move name lookup out of nfsd4_list_rec_dir()", " - nfsd: change nfs4_client_to_reclaim() to allocate data", " - arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative", " - arm64: Fix early handling of FEAT_E2H0 not being implemented", " - KVM: arm64: Initialize HCR_EL2.E2H early", " - arm64: Revamp HCR_EL2.E2H RES1 detection", " - arm64: sysreg: Correct sign definitions for EIESB and DoubleLock", " - iio: adc: spear: Initialize completion before requesting IRQ", " - iio: imu: inv_icm42600: fix timestamp clock period by using lower value", " - ALSA: usb-audio: Roll back quirk control caches on write errors", " - usb: typec: tcpci_rt1711h: unregister TCPCI port with devres", " - gpio: eic-sprd: use raw_spinlock_t in the irq startup path", " - netfilter: ebtables: module names must be null-terminated", " - netfilter: ebtables: terminate table name before find_table_lock()", " - Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()", " - Bluetooth: bnep: pin L2CAP connection during netdev registration", " - Bluetooth: btnxpuart: Fix out-of-bounds firmware read in", " nxp_recv_fw_req_v3()", " - Bluetooth: fix UAF in bt_accept_dequeue()", " - Bluetooth: L2CAP: validate option length before reading conf opt value", " - fs/ntfs3: fsync files by syncing parent inodes", " - fs/ntfs3: zero-fill folios beyond i_valid in ntfs_read_folio()", " - fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()", " - coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer()", " - smb/client: Fix error code in smb2_aead_req_alloc()", " - ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE", " - ksmbd: add a permission check for FSCTL_SET_ZERO_DATA", " - ksmbd: serialize QUERY_DIRECTORY requests per file", " - ksmbd: require source read access for duplicate extents", " - ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock", " cancellation", " - ksmbd: add a WRITE_DAC/WRITE_OWNER check to SMB2 SET_INFO SECURITY", " - ksmbd: run set info with opener credentials", " - ksmbd: enforce FILE_READ_ATTRIBUTES on SMB_FIND_FILE_POSIX_INFORMATION", " - ksmbd: add per-handle permission check to FILE_LINK_INFORMATION", " - ksmbd: use opener credentials for delete-on-close", " - smb: client: fix query directory replay double-free", " - smb: client: fix query_info() replay double-free", " - smb: client: fix double-free in SMB2_ioctl() replay", " - smb: client: fix change notify replay double-free", " - smb: client: fix double-free in SMB2_flush() replay", " - smb: client: fix double-free in SMB2_open() replay", " - smb: client: fix double-free in SMB2_close() replay", " - smb: client: Fix next buffer leak in receive_encrypted_standard()", " - smb: client: use unaligned reads in parse_posix_ctxt()", " - smb: client: harden POSIX SID length parsing", " - smb: client: mask server-provided mode to 07777 in modefromsid", " - OPP: of: Fix potential memory leak in opp_parse_supplies()", " - firmware_loader: fix device reference leak in firmware_upload_register()", " - cpufreq: intel_pstate: Sync policy->cur during CPU offline", " - sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT", " - cpufreq: Fix hotplug-suspend race during reboot", " - cpufreq: pcc: fix use-after-free and double free in _OSC evaluation", " - posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path", " - clocksource/drivers/timer-tegra186: Fix support for multiple watchdog", " instances", " - X.509: Fix validation of ASN.1 certificate header", " - tools/mm/slabinfo: Fix trace disable logic inversion", " - tools/mm/slabinfo: fix total_objects attribute name", " - HID: wacom: stop hardware after post-start probe failures", " - HID: letsketch: fix UAF on inrange_timer at driver unbind", " - HID: lg-g15: cancel pending work on remove to fix a use-after-free", " - HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte", " reads", " - hfs/hfsplus: zero-initialize buffer in hfs_bnode_read", " - nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers", " - media: mtk-jpeg: cancel workqueue on release for supported platforms", " only", " - xfs: use null daddr for unset first bad log block", " - xfs: fix unreachable BIGTIME check in dquot flush validation", " - bpf: Reject fragmented frames in devmap", " - bpf: Restore sysctl new-value from 1 to 0", " - net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()", " - usb: cdc_acm: Add quirk for Uniden BC125AT scanner", " - usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()", " - USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub", " - usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()", " - usb: free iso schedules on failed submit", " - usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler", " - usb: gadget: udc: Fix use-after-free in gadget_match_driver", " - usb: gadget: f_printer: take kref only for successful open", " - USB: idmouse: fix use-after-free on disconnect race", " - USB: ldusb: fix use-after-free on disconnect race", " - USB: iowarrior: fix use-after-free on disconnect", " - USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD", " - USB: legousbtower: fix use-after-free on disconnect race", " - usb: sl811-hcd: disable controller wakeup on remove", " - USB: storage: include US_FL_NO_SAME in quirks mask", " - USB: misc: uss720: unregister parport on probe failure", " - usb: mtu3: unmap request DMA on queue failure", " - USB: serial: keyspan_pda: fix information leak", " - USB: serial: option: add Telit Cinterion FE990D50 compositions", " - USB: serial: digi_acceleport: fix broken rx after throttle", " - USB: serial: digi_acceleport: fix hard lockup on disconnect", " - USB: serial: digi_acceleport: fix write buffer corruption", " - USB: ulpi: fix memory leak on registration failure", " - USB: usb-storage: ene_ub6250: restore media-ready check", " - usbip: tools: support SuperSpeedPlus devices", " - usbip: vudc: fix NULL deref in vep_dequeue()", " - usb: typec: anx7411: use devm_pm_runtime_enable()", " - usb: typec: class: drop PD lookup reference", " - usb: typec: tcpm: Validate SVID index in svdm_consume_modes()", " - usb: typec: ucsi: Invert DisplayPort role assignment", " - usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt", " mode", " - usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove", " - usb: typec: ucsi: cancel pending work on system suspend", " - iio: temperature: ltc2983: Fix n_wires default bypassing rotation check", " - PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining", " - udf: validate free block extents against the partition length", " - udf: validate VAT header length against the VAT inode size", " - udf: validate sparing table length as an entry count, not a byte count", " - hwrng: jh7110 - fix refcount leak in starfive_trng_read()", " - dm-ioctl: report an error if a device has no table", " - nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace", " disks", " - btrfs: do not trim a device which is not writeable", " - partitions: aix: bound the pp_count scan to the ppe array", " - isofs: bound Rock Ridge symlink components to the SL record", " - crypto: af_alg - Remove zero-copy support from skcipher and aead", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps again", " - crypto: ecc - Fix carry overflow in vli multiplication", " - crypto: pcrypt - restore callback for non-parallel fallback", " - crypto: drbg - Fix returning success on failure in CTR_DRBG", " - crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels", " - crypto: drbg - Fix the fips_enabled priority boost", " - crypto: qat - validate RSA CRT component lengths", " - crypto: talitos - use dma_sync_single_for_cpu() before reading", " descriptor header", " - crypto: talitos - add chaining of arbitrary number of descriptor for the", " SEC1", " - crypto: talitos - move dma unmapping code in flush_channel() into a", " standalone dma_unmap_request() function", " - crypto: talitos - move dma mapping code in talitos_submit() into a", " standalone dma_map_request() function", " - crypto: talitos - move code in current_desc_hdr() into a standalone", " function", " - crypto: talitos/hash - prepare SEC1 descriptor chaining, remove", " additional descriptor", " - crypto: talitos/hash - use descriptor chaining for SEC1 instead of", " workqueue", " - crypto: talitos/hash - drop workqueue mechanism for SEC1", " - crypto: talitos/hash - rename first_desc/last_desc to", " first_request/last_request", " - crypto: talitos/hash - remove useless wrapper", " - crypto: talitos/hash - fix SEC2 64k - 1 ahash request limitation", " - arm64: fpsimd: Fix type mismatch in sme_{save,load}_state()", " - spi: fsl-lpspi: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - spi: fsl-lpspi: terminate the RX channel on TX prepare failure path", " - EDAC/i10nm: Don't fail probing if ADXL is missing", " - watchdog: apple: Add \"apple,t8103-wdt\" compatible", " - tracing: Prevent out-of-bounds read in glob matching", " - NFSv4: include MAY_WRITE in open permission mask for O_TRUNC", " - module: decompress: check return value of module_extend_max_pages()", " - exfat: bound uniname advance in exfat_find_dir_entry()", " - NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()", " - KVM: VMX: Refresh GUEST_PENDING_DBG_EXCEPTIONS.BS on all injected #DBs", " - KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest", " mode", " - udmabuf: fix DMA direction mismatch in release_udmabuf()", " - i2c: core: fix adapter deregistration race", " - i2c: mpc: Fix timeout calculations", " - i2c: stm32f7: truncate clock period instead of rounding it", " - Input: synaptics-rmi4 - unregister function handlers on physical driver", " registration failure", " - Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count", " - Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count", " - Input: elan_i2c - prevent division by zero and arithmetic underflow", " - Input: goodix - clamp the device-reported contact count", " - Input: iforce - bound the device-reported force-feedback effect index", " - Input: mms114 - fix touch indexing for MMS134S and MMS136", " - Input: touchwin - reset the packet index on every complete packet", " - Input: mms114 - reject an oversized device packet size", " - Input: maplemouse - fix NULL pointer dereference in open()", " - Input: mms114 - fix multi-touch slot corruption", " - Input: maple_keyb - set driver data before registering input device", " - Input: maplemouse - set driver data before registering input device", " - Input: maplecontrol - set driver data before registering input device", " - RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", " - fuse: fix device node leak in cuse_process_init_reply()", " - fuse: re-lock request before returning from fuse_ref_folio()", " - smb: client: reject overlapping data areas in SMB2 responses", " - xfs: fail recovery on a committed log item with no regions", " - xfs: resample the data fork mapping after cycling ILOCK", " - smb/server: do not require delete access for non-replacing links", " - sched/fair: Only update stats for allowed CPUs when looking for dst", " group", " - KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU", " - KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove CRYPTO_DEV_SUN4I_SS_PRNG", " - crypto: crypto4xx - Remove ahash-related code", " - bpf: Support for hardening against JIT spraying", " - x86/bugs: Enable IBPB flush on BPF JIT allocation", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix sequence number when no EOF", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - dt-bindings: power: imx93: Add MIPI PHY power domain", " - serial: msm: Disable DMA for kernel console UART", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: Fix further netns teardown to cancel the preallocation charger", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/amdgpu: fix integer overflow in amdgpu_gem_align_pitch()", " - drm/radeon: fix integer overflow in radeon_align_pitch()", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " - libbpf: Report error when a negative kprobe offset is specified", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg", " warning", " - wifi: cfg80211: fix grammar in MLO group key error message", " - arm64: tegra: Fix Tegra234 MGBE PTP clock", " - dt-bindings: pinctrl: nvidia,tegra234: Add missing required block", " - drm/amdkfd: Validate CRIU-restored IDs before idr_alloc", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sama5d4_wdt: Fix WDDIS detection on SAM9X60 and SAMA7G5", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - media: v4l2-common: Add YUV24 format info", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " - dlm: fix add msg handle in send_queue ordered", " - nilfs2: fix backing_dev_info reference leak", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - evm: terminate and bound the evm_xattrs read buffer", " - thermal: hwmon: Fix critical temperature attribute removal", " - clk: scpi: Unregister child clock providers on remove", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - spi: hisi-kunpeng: Use dev_err_probe() for host registration failure", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/srpt: fix integer overflow in immediate data length check", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - driver core: Use mod_delayed_work to prevent lost deferred probe work", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - bus: sunxi-rsb: Always check register address validity", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: seq: midi: Serialize output teardown with event_input", " - pinctrl: cs42l43: Fix polarity on debounce", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " - drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X", " client is registered", " - drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove", " - gpu: host1x: Allow entries in BO caches to be freed", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - gpu: host1x: Fix iommu_map_sgtable() return value check", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Harden parse_vma_segs() path parsing", " - libbpf: Fix UAF in strset__add_str()", " - dax/kmem: account for partial discontiguous resource upon removal", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - rpmsg: use generic driver_override infrastructure", " - md/raid10: reset read_slot when reusing r10bio for discard", " - RDMA/siw: bound Read Response placement to the RREAD length", " - block: skip sync_blockdev() on surprise removal in bdev_mark_dead()", " - crypto: algif_skcipher - force synchronous processing", " - crypto: crypto4xx - Remove insecure and unused rng_alg", " - crypto: hisi-trng - Remove crypto_rng interface", " - bpf: Restrict JIT predictor flush to cBPF", " - bpf: Skip redundant IBPB in pack allocator", " - bpf: Prefer packs that won't trigger an IBPB flush on allocation", " - bpf: Prefer dirty packs for eBPF allocations", " - clk: scmi: Fix clock rate rounding", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - bitops: use common function parameter names", " - media: rockchip: rga: fix too small buffer size", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - scsi: ufs: Fix wrong value printed in unexpected UPIU response case", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " - mm/fake-numa: fix under-allocation detection in uniform split", " - ext2: fix ignored return value of generic_write_sync()", " - sched: restore timer_slack_ns when resetting RT policy on fork", " - lib/test_meminit: use && for bools", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: reject FITRIM ranges shorter than a cluster", " - ocfs2/dlm: require a ref for locking_state debugfs open", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - bpf: Check tail zero of bpf_prog_info", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - wifi: wcn36xx: fix heap overflow from oversized firmware HAL response", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " - wifi: wcn36xx: fix OOB read from short trigger BA firmware response", " - ALSA: seq: Fix partial userptr event expansion", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - scsi: target: Fix hexadecimal CHAP_I handling", " - scsi: target: Remove tcm_loop target reset handling", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " - hwspinlock: qcom: avoid uninitialized struct members", " - sched/fair: Fix cpu_util runnable_avg arithmetic", " - wifi: mt76: fix argument to ieee80211_is_first_frag()", " - wifi: mt76: mt7915: fix potential tx_retries underflow", " - wifi: mt76: mt7921: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - spi: meson-spifc: fix runtime PM leak on remove", " - ASoC: codecs: aw88261: fix incorrect masks for boost regs", " - vduse: hold vduse_lock across IDR lookup in open path", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " - vduse: Requeue failed read to send_list head", " - vhost/net: complete zerocopy ubufs only once", " - tools/virtio: check mmap return value in vringh_test", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - bonding: 3ad: fix mux port state on oper down", " - ext4: fix kernel BUG in ext4_write_inline_data_end", " - selftests/bpf: Fix bpf_iter/task_vma test", " - cxl/test: Fix integer overflow in mock LSA bounds checks", " - cxl/test: Zero out LSA backing memory to avoid leaking to user", " - of: cpu: add check in __of_find_n_match_cpu_property()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " - RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " - ASoC: fsl: fsl_audmix: Validate written enum values", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " - net/sched: cls_flow: Dont expose folded kernel pointers", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " - bridge: cfm: reject invalid CCM interval at configuration time", " - sctp: validate embedded address parameter length", " - net/sched: sch_hfsc: Don't make class passive twice", " - tipc: require net admin for TIPCv2 netlink mutators", " - tipc: prevent snt_unacked underflow on CONN_ACK", " - tipc: reject inverted service ranges from peer bindings", " - cxl/test: Add check after kzalloc() memory in alloc_mock_res()", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " - crypto: rng - Free default RNG on module exit", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - power: supply: core: fix supplied_from allocations", " - handshake: Require admin permission for DONE command", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - net: wwan: t7xx: check skb_clone in control TX", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - netfilter: nf_conncount: callers must hold rcu read lock", " - ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait()", " - cifs: remove all cifs files before kill super", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - tipc: fix UAF in tipc_l2_send_msg()", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - ionic: Fix check in ionic_get_link_ext_stats", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - coresight: cti: Fix DT filter signals silently ignored", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - PCI/ASPM: Don't reconfigure ASPM entering low-power state", " - PCI: Introduce named defines for PCI ROM", " - PCI: Check ROM header and data structure addr before accessing", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - mailbox: mtk-adsp: fix UAF during device teardown", " - staging: most: video: avoid double free on video register failure", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " - iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " - iio: tcs3472: power down chip on probe failure", " - clk: at91: keep securam node alive while mapping it", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - fs/ntfs3: add bounds check to run_get_highest_vcn()", " - fs/ntfs3: fix mount failure on 64K page-size kernels", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - pNFS/filelayout: fix cheking if a layout is striped", " - xprtrdma: Remove temp allocation of rpcrdma_rep objects", " - xprtrdma: Avoid 250 ms delay on backlog wakeup", " - xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot", " - xprtrdma: Post receive buffers after RPC completion", " - xprtrdma: Use sendctx DMA state for Send signaling", " - xprtrdma: Decouple req recycling from RPC completion", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - nfs: keep PG_UPTODATE clear after read errors in page groups", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Fix bcall rep leak and unbounded peek", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - apparmor: fix rawdata_f_data implicit flex array", " - apparmor: fix potential UAF in aa_replace_profiles", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - sparc: led: avoid trimming a newline from empty writes", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - spi: dw: fix wrong BAUDR setting after resume", " - xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO", " path", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " - PCI: iproc: Restore .map_irq() for the platform bus driver", " - spi: rpc-if: Use correct device for hardware reinitialization on resume", " - virtio-net: fix len check in receive_big()", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - flow_dissector: check device type before reading ETH_ADDRS", " - ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: Fix data race between add and dump in all hash types", " - netfilter: ipset: annotate \"pos\" for concurrent readers/writers", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash", " types", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - irqchip/crossbar: Fix parent domain resource leak", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - net: marvell: prestera: initialize err in prestera_port_sfp_bind", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " - net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths", " - octeontx2-af: mcs: Fix unsupported secy stats read", " - octeontx2-pf: Clear stats of all resources when freeing resources", " - octeontx2-pf: mcs: Fix mcs resources free on PF shutdown", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: Fix stack slot index in nospec checks", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()", " - ice: fix AQ error code comparison in ice_set_pauseparam()", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - ipv4: fib: Don't ignore error route in local/main tables.", " - bpf, lsm: Add disabled BPF LSM hook list", " - bpf: Disable xfrm_decode_session hook attachment", " - netfilter: nf_nat: avoid invalid nat_net pointer use on failed", " nf_nat_init()", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - netfilter: nft_compat: ebtables emulation must reject non-bridge targets", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - NTB: epf: Report 0-based doorbell vector via ntb_db_event()", " - NTB: epf: Fix doorbell bitmask and IRQ vector handling", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - net, bpf: check master for NULL in xdp_master_redirect()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - net: mvneta: re-enable percpu interrupt on resume", " - net: sungem: fix probe error cleanup", " - net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - net: enetc: check the number of BDs needed for xdp_frame", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - apparmor: check label build before no_new_privs test", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - net/sched: sch_teql: Introduce slaves_lock to avoid race condition and", " UAF", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - cxgb4: Fix decode strings dump for T6 adapters", " - virtio_net: disable cb when NAPI is busy-polled", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - ksmbd: reject undersized DACLs before parsing ACEs", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - pinctrl: meson: restore non-sleeping GPIO access", " - net/sched: hhf: clear heavy-hitter state on reset", " - fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid", " - afs: Fix error code in afs_extract_vl_addrs()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix vllist leak", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " - afs: Fix unchecked-length string display in debug statement", " - minix: avoid overflow in bitmap block count calculation", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: convert READ_ONCE(*ptep) to ptep_get(ptep)", " - arm64/mm: convert set_pte_at() to set_ptes(..., 1)", " - arm64/mm: convert ptep_clear() to ptep_get_and_clear()", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - selftests/hid: convert the hid_bpf selftests with struct_ops", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - gue: validate REMCSUM private option length", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " - amt: fix size calculation in amt_get_size()", " - Bluetooth: 6lowpan: hold L2CAP conn across debugfs control", " - Bluetooth: MGMT: Fix adv monitor add failure cleanup", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - ring-buffer: Fix event length with forced 8-byte alignment", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: move functions to avoid forward definitions", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " - ipv6: mcast: Replace locking comments with lockdep annotations.", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " - s390/zcrypt: Remove the empty file", " - cifs: validate DFS referral string offsets", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " - dm era: fix NULL pointer dereference in metadata_open()", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " - selftests/net: fix EVP_MD_CTX leak in tcp_mmap", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - octeontx2-af: fix VF bringup affecting PF promiscuous state", " - smb: client: fix overflow in passthrough ioctl bounds check", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " - ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put", " - ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc", " - ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get", " - ASoC: SOF: topology: validate vendor array size before parsing", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " - net: atm: reject out-of-range traffic classes in QoS validation", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " - fbdev: vesafb: fix memory leak in vesafb_probe()", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " - ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get", " - ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Release reserved memory on cleanup", " - ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_cluster: reject template conntracks in hash match", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - netfilter: nf_nat_sip: reload possible stale data pointer", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " - netfilter: ecache: fix inverted time_after() check", " - netfilter: xt_nat: reject unsupported target families", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - selinux: check connect-related permissions on TCP Fast Open", " - leds: uleds: Fix potential buffer overread", " - mfd: sm501: Fix reference leak on failed device registration", " - tools/power/x86/intel-speed-select: Harden daemon pidfile open", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " - x86/boot: Reject too long acpi_rsdp= values", " - perf/x86/amd/lbr: Fix kernel address leakage", " - s390/perf_cpum_cf: Add missing array_index_nospec() to", " __hw_perf_event_init()", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: bla: reacquire gw address after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: tt: avoid request storms during pending request", " - batman-adv: fix VLAN priority offset", " - batman-adv: frag: free unfragmentable packet", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: tt: prevent TVLV OOB check overflow", " - cifs: invalidate cfid on unlink/rename/rmdir", " - mfd: tps6586x: Fix OF node refcount", " - HID: playstation: validate num_touch_reports in DualShock 4 reports", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " - nvdimm/btt: Free arenas on btt_init() error paths", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - mm/damon/core: make charge_addr_from aware of end-address exclusivity", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " - fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " - riscv: cacheinfo: Fix node reference leak in populate_cache_leaves", " - mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs()", " - mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error", " - proc: only bump parent nlink when registering directories", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - mtd: rawnand: pl353: fix probe resource allocation", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " - mtd: rawnand: fix condition in 'nand_select_target()'", " - ocfs2: avoid moving extents to occupied clusters", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " - ocfs2: add journal NULL check in ocfs2_checkpoint_inode()", " - ocfs2: reject dinodes with non-canonical i_mode type", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " - fpga: dfl: add bounds check in dfh_get_param_size()", " - bus: mhi: ep: Protect mhi_ep_handle_syserr() in the error path", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - fpga: microchip-spi: fix zero header_size OOB read in", " mpf_ops_parse_header()", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86/amd/pmc: Check for intermediate wakeup in function", " - platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops", " - platform/x86/amd/pmc: Add delay_suspend module parameter", " - smb: client: use kvzalloc() for megabyte buffer in simple fallocate", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - ice: fix ice_init_link() error return preventing probe", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - tpm: Make the TPM character devices non-seekable", " - time: Fix off-by-one in compat settimeofday() usec validation", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " - sctp: validate STALE_COOKIE cause length before reading staleness", " - nvmet-rdma: handle inline data with a nonzero offset", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " - can: bcm: add missing rcu list annotations and operations", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - net: sparx5: unregister blocking notifier on init failure", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " - dm era: fix out-of-bounds memory access for non-zero start sector", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-ioctl: fix a possible overflow in list_version_get_info", " - dm-log: fix a bitset_size overflow on 32bit machines", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm_early_create: fix freeing used table on dm_resume failure", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - scsi: sg: Report request-table problems when any status is set", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - validate control endpoint type", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - Input: ims-pcu - fix race condition in reset_device sysfs callback", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " - net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio-f7188x: Add support for NCT6126D version B", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: wwan: t7xx: destroy DMA pool on CLDMA late init failure", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - net: ena: clean up XDP TX queues when regular TX setup fails", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " - ieee802154: admin-gate legacy LLSEC dump operations", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " - batman-adv: ensure minimal ethernet header on TX", " - batman-adv: clean untagged VLAN on netdev registration failure", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - espintcp: use sk_msg_free_partial to fix partial send", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: mpfs: fix counter upload completion condition", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - net: liquidio: fix BAR resource leak on PF number failure", " - hwmon: (occ) unregister sysfs devices outside occ lock", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - net: lan743x: Initialize eth_syslock spinlock before use", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - net: wwan: iosm: bound device offsets in the MUX downlink decoder", " - hwmon: (asus_atk0110) Check package count before accessing element", " - riscv: probes: save original sp in rethook trampoline", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - drbd: reject data replies with an out-of-range payload size", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " - pmdomain: imx: Fix i.MX8MP power notifier", " - pmdomain: imx: Fix i.MX8MP VC8000E power up sequence", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - Bluetooth: btrtl: validate firmware patch bounds", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - memstick: ms_block: reject a card that reports too many blocks", " - ipvs: fix more places with wrong ipv6 transport offsets", " - ipvs: reload ip header after head reallocation", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: mac80211: free ack status frame on TX header build failure", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " - mtd: onenand: samsung: report DMA completion timeouts", " - mtd: mchp23k256: use SPI match data for chip caps", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " - perf/x86/amd/brs: Fix kernel address leakage", " - ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup", " - ACPI: bus: Introduce devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Use devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Fix possible deadlock and missing notifications", " - iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - iio: invensense: remove redundant initialization of variable period", " - iio: invensense: fix timestamp glitches when switching frequency", " - iio: imu: inv_icm42600: stabilized timestamp in interrupt", " - iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading", " - iio: pressure: mpl115: fix runtime PM leak on read error", " - bitops: make BYTES_TO_BITS() treewide-available", " - iio: common: st_sensors: honour channel endianness in read_axis_data", " - ALSA: aoa: check snd_ctl_new1() return value", " - PCI: altera: Fix resource leaks on probe failure", " - vfio/mlx5: Fix racy bitfields and tighten struct layout", " - PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling", " - PCI: controller: Use dev_fwnode() instead of of_fwnode_handle()", " - PCI: mediatek: Convert bool to single quirks entry and bitmap", " - PCI: mediatek: Use generic MACRO for TPVPERL delay", " - PCI: mediatek: Fix IRQ domain leak when port fails to enable", " - PCI: Prevent resource tree corruption when BAR resize fails", " - PCI: Free saved list without holding pci_bus_sem", " - PCI: Fix restoring BARs on BAR resize rollback path", " - PCI: Add kerneldoc for pci_resize_resource()", " - PCI: Move Resizable BAR code to rebar.c", " - PCI: Skip Resizable BAR restore on read error", " - staging: rtl8723bs: core: move constants to right side in comparison", " - staging: rtl8723bs: fix spaces around binary operators", " - staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),", " rtw_get_wapi_ie(), and rtw_get_wps_attr()", " - crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()", " - Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref", " - mm/shrinker: do not hold RCU lock in shrinker_debugfs_count_show()", " - coresight: etb10: restore atomic_t for shared reading state", " - gpio: sch: use raw_spinlock_t in the irq startup path", " - media: nxp: imx8-isi: Convert to platform remove callback returning void", " - media: nxp: imx8-isi: use devm_pm_runtime_enable() to simplify code", " - media: nxp: imx8-isi: Fix use-after-free on remove", " - netfilter: ebtables: Use vmalloc_array() to improve code", " - netfilter: ebtables: zero chainstack array", " - Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - smb: client: Improve unlocking of a mutex in cifs_get_swn_reg()", " - smb: client: resolve SWN tcon from live registrations", " - ksmbd: use opener credentials for FSCTL mutations", " - ksmbd: centralize ksmbd_conn final release to plug transport leak", " - ksmbd: track the connection owning a byte-range lock", " - proc: rename proc_setattr to proc_nochmod_setattr", " - proc: protect ptrace_may_access() with exec_update_lock (FD links)", " - writeback: fix race between cgroup_writeback_umount() and", " inode_switch_wbs()", " - perf/x86/intel/uncore: Defer ADL global PMON enable to enable_box()", " - HID: add haptics page defines", " - HID: multitouch: fix out-of-bounds bit access on mt_io_flags", " - mm/slab: do not limit zeroing to orig_size when only red zoning is", " enabled", " - seqlock: Introduce scoped_seqlock_read()", " - seqlock: Change do_task_stat() to use scoped_seqlock_read()", " - proc: protect ptrace_may_access() with exec_update_lock (part 1)", " - treewide: Switch/rename to timer_delete[_sync]()", " - HID: appleir: fix UAF on pending key_up_timer in remove()", " - serial: 8250_mid: Disable DMA for selected platforms", " - hfs/hfsplus: prevent getting negative values of offset/length", " - hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length", " - bpf: Consistently use bpf_rcu_lock_held() everywhere", " - bpf: Allow LPM map access from sleepable BPF programs", " - usb: iowarrior: remove inherent race with minor number", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - usb: typec: tcpm: Fix VDM type for Enter Mode commands", " - crypto: atmel - Drop explicit initialization of struct", " i2c_device_id::driver_data to 0", " - crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A", " - usb: gadget: f_fs: initialize reset_work at allocation time", " - nvmet: return DHCHAP status codes from nvmet_setup_auth()", " - nvmet-auth: validate reply message payload bounds against transfer", " length", " - usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile", " - btrfs: check and set EXTENT_DELALLOC_NEW before clearing EXTENT_DELALLOC", " - crypto: qat - fix restarting state leak on allocation failure", " - audit: add audit_log_nf_skb helper function", " - audit: fix potential integer overflow in audit_log_n_hex()", " - regulator: scmi: Simplify with scoped for each OF child loop", " - regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()", " - mm: do file ownership checks with the proper mount idmap", " - exfat: move free cluster out of exfat_init_ext_entry()", " - exfat: remove unnecessary read entry in __exfat_rename()", " - exfat: rename argument name for exfat_move_file and exfat_rename_file", " - exfat: add exfat_get_dentry_set_by_ei() helper", " - exfat: move exfat_chain_set() out of __exfat_resolve_path()", " - exfat: preserve benign secondary entries during rename and move", " - btrfs: fix false IO failure after falling back to buffered write", " - btrfs: fix incorrect buffered IO fallback for append direct writes", " - Bluetooth: hci_core: Enable buffer flow control for SCO/eSCO", " - Bluetooth: separate CIS_LINK and BIS_LINK link types", " - Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - seqlock: fix scoped_seqlock_read kernel-doc", " - Bluetooth: hci_core: Remove check of BDADDR_ANY in", " hci_conn_hash_lookup_big_state", " - Bluetooth: hci_sync: Fix attempting to send HCI_Disconnect to BIS handle", " - Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote", " netdev", " - selftests/hid: ensure CKI can compile our new tests on old kernels", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error harder", " - Bluetooth: btmtk: remove #ifdef around declarations", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - jiffies: Define secs_to_jiffies()", " - jiffies: Cast to unsigned long in secs_to_jiffies() conversion", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - tools/testing: add linux/args.h header and fix radix, VMA tests", " - selftests/bpf: Add simple strscpy() implementation", " - bcachefs: avoid truncating fiemap extent length", " - gpio: rockchip: change the GPIO version judgment logic", " - gpio: rockchip: teardown bugs and resource leaks", " - gpio: rockchip: fix generic IRQ chip leak on remove", " - NFSv4/flexfiles: Remove cred local variable dependency", " - iio: resolver: ad2s1210: notify trigger and clear state on fault read", " error", " - iio: temperature: Build mlx90635 with CONFIG_MLX90635", " - vfio: Remove device debugfs before releasing devres", " - PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000", " series", " - netpoll: fix a use-after-free on shutdown path", " - mm: shrinker: fix shrinker_info teardown race with expansion", " - NFSv4/flexfiles: Add data structure support for striped layouts", " - mm/khugepaged: write all dirty file folios when collapsing", " - platform/x86: intel-hid: Protect ACPI notify handler against recursion", " - Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled", " - Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()", " - fs/ntfs3: rename ni_readpage_cmpr into ni_read_folio_cmpr", " - ksmbd: use __GFP_RETRY_MAYFAIL", " - ksmbd: use opener credentials for ADS I/O", " - cpufreq: Make cpufreq_driver->exit() return void", " - cpufreq: qcom-cpufreq-hw: Fix possible double free", " - nvme: target: rdma: fix ndev refcount leak on queue connect", " - nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page", " - crypto: qat - keep VFs enabled during reset", " - crypto: qat - notify fatal error before AER reset preparation", " - crypto: qat - protect service table iterations with service_lock", " - selftests/mm: pagemap_ioctl: use the correct page size for", " transact_test()", " - iommufd: Set upper bounds on cache invalidation entry_num and entry_len", " - iommu/amd: Don't split flush for amd_iommu_domain_flush_all()", " - dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning", " - i2c: core: fix adapter probe deferral loop", " - xfs: fix null pointer dereference in tracepoint", " - xfs: don't wrap around quota ids in dqiterate", " - xfs: clamp timestamp nanoseconds correctly", " - xfs: don't zap bmbt forks if they are MAXLEVELS tall", " - iommu/vt-d: Clear Present bit before tearing down context entry", " - iommu: Pass old domain to set_dev_pasid op", " - iommu/vt-d: Cleanup intel_context_flush_present()", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " - vsock/virtio: bind uarg before filling zerocopy skb", " - iommu/amd: Use maximum Event log buffer size when SNP is enabled on", " Family 0x19", " - iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family", " 0x19", " - net: dropreason: Gather SOCKET_ drop reasons.", " - af_unix: Set drop reason in unix_release_sock().", " - af_unix: Set drop reason in manage_oob().", " - af_unix: Set drop reason in unix_stream_read_skb().", " - af_unix/scm: fix whitespace errors", " - af_unix: Don't hold unix_state_lock() in __unix_dgram_recvmsg().", " - af_unix: Don't check SOCK_DEAD in unix_stream_read_skb().", " - af_unix: Don't use skb_recv_datagram() in unix_stream_read_skb().", " - af_unix: Drop all SCM attributes for SOCKMAP.", " - time/jiffies: Change register_refined_jiffies() to void __init", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - media: uvcvideo: Do not add clock samples with small sof delta", " - serial: max310x: replace bare use of 'unsigned' with 'unsigned int'", " (checkpatch)", " - serial: max310x: implement gpio_chip::get_direction()", " - drm/gpuvm: Do not prepare NULL objects", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - soc: xilinx: Shutdown and free rx mailbox channel", " - crypto: qat - fix heartbeat error injection", " - memory: tegra: Wire up system sleep PM ops", " - drm/gpuvm: take refcount on DRM device", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - RDMA/hns: Initialize seqfile before creating file", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - RDMA/hns: Fix log flood after cmd_mbox failure", " - net: introduce page_frag_cache_drain()", " - nvmet-tcp: fix page fragment cache leak in error path", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - driver core: Use system_percpu_wq instead of system_wq", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - x86/cpu/amd: Provide a separate accessor for Node ID", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - netfilter: nfnetlink_cthelper: use {READ,WRITE}_ONCE for accessing", " helper flags", " - netfilter: synproxy: drop packets if timestamp adjustment fails", " - netfilter: synproxy: adjust duplicate timestamp options", " - netfilter: synproxy: fix unaligned memory access in timestamp adjustment", " - RDMA/siw: Fix endpoint/socket association handling", " - riscv: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - virtio_console: read size from config space during device init", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - net: dsa: qca8k: fix led devicename when using external mdio bus", " - ALSA: seq: Drop superfluous filter argument of get_event_dest_client()", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - dpll: add reference-sync netlink attribute", " - dpll: move xa_erase() call in to match dpll_pin_alloc() error path order", " - dpll: add reference sync get/set", " - dpll: Allow associating dpll pin with a firmware node", " - dpll: Add notifier chain for dpll events", " - dpll: Support dynamic pin index allocation", " - dpll: Enhance and consolidate reference counting logic", " - dpll: fix stale iteration in dpll_pin_on_pin_unregister()", " - dpll: send delete notification before unregister in on-pin rollback", " - dpll: emit per-dpll delete notifications in dpll_pin_on_pin_unregister()", " - dpll: guard sync-pair removal on full pin unregister", " - dpll: balance create/delete notifications in __dpll_pin_(un)register", " - landlock: Fix unmarked concurrent access to socket family", " - selftests/bpf: Fix typo in verify_umulti_link_info", " - udf: fix nls leak on udf_fill_super() failure", " - mfd: rsmu: Fix page register setup", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: split ep_insert() into alloc + register stages", " - eventpoll: extract ep_deliver_event() from ep_send_events()", " - eventpoll: wrap EP_UNACTIVE_PTR in typed sentinel helpers", " - eventpoll: rename epi->next and txlist for clarity", " - eventpoll: Fix epoll_wait() report false negative", " - gpiolib: acpi: Only trigger ActiveBoth interrupts on boot", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - PCI: meson: Add missing remove callback", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - workqueue: Add new WQ_PERCPU flag", " - i3c: master: add WQ_PERCPU to alloc_workqueue users", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - xfrm: Fix xfrm state cache insertion race", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - netfilter: ipset: make sure gc is properly stopped", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: hugetlb_reparenting_test: do not unmount", " - selftests/mm: save and restore nr_hugepages value", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - ipv6: annotate data-races around cnf.forwarding", " - ipv6/addrconf: annotate data-races around devconf fields (II)", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_info", " - ice: dpll: fix memory leak in ice_dpll_init_info error paths", " - net: bnxt: use ethtool string helpers", " - eth: bnxt: gather and report HW-GRO stats", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - ipv6: Add __in6_dev_get_rtnl_net().", " - octeontx2-af: Validate NIX maximum LFs correctly", " - udp_tunnel: remove rtnl_lock dependency", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - net: hisilicon: hns3: use ethtool string helpers", " - net: hns3: use string choices helper", " - net: hns3: use hns3_get_ae_dev() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: use hns3_get_ops() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: clear hns alarm: comparison of integer expressions of", " different signedness", " - net: hns3: unify copper port ksettings configuration path", " - net: hns3: refactor MAC autoneg and speed configuration", " - net: hns3: fix permanent link down deadlock after reset", " - net: hns3: differentiate autoneg default values between copper and fiber", " - rtnetlink: Add per-netns RTNL.", " - [Config] Set CONFIG_DEBUG_NET_SMALL_RTNL=n", " - rtnetlink: Add assertion helpers for per-netns RTNL.", " - rtnetlink: Define rtnl_net_trylock().", " - ipv6: Convert net.ipv6.conf.${DEV}.XXX sysctl to per-netns RTNL.", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Make /afs/. as well as /afs/ mountpoints", " - afs: Add rootcell checks", " - afs: Make /afs/@cell and /afs/.@cell symlinks", " - afs: Fix afs_atcell_get_link() to handle RCU pathwalk", " - afs: Remove the \"autocell\" mount option", " - afs: Change dynroot to create contents on demand", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - ovl: fix comment about locking order", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - afs: Convert comma to semicolon", " - afs: Fix double netfs initialisation in afs_root_iget()", " - drm/xe: Add warn when level can not be zero.", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - HID: bpf: Fix hid_bpf_get_data() range check", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - genirq/generic_chip: Introduce irq_domain_{alloc,remove}_generic_chips()", " - gpio: mvebu: free generic chips on unbind", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " - drm/xe: remove duplicate include", " - LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()", " - LoongArch: KVM: Check the return values for put_user()", " - LoongArch: KVM: Fix FPU register width with user access API", " - LoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr()", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - fbdev: efifb: fix memory leak in efifb_probe()", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - batman-adv: mcast: avoid OOB read of num_dests header", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()", " - fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry()", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - taskstats: retain dead thread stats in TGID queries", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - NFS: Charge unstable writes by request size, not folio size", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: make error counter atomic", " - accel/ivpu: Reject firmware log with size smaller than header", " - firmware_loader: introduce __free() cleanup hanler", " - Input: ims-pcu - fix firmware leak in async update", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - gpio: tegra: do not call pinctrl for GPIO direction", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - s390: Revert support for DCACHE_WORD_ACCESS", " - [Config] Set CONFIG_DCACHE_WORD_ACCESS=- for s390x", " - selftests: net: make busywait timeout clock portable", " - ata: libata: Use QUIRK instead of HORKAGE", " - ata: libata-core: Skip HPA resize for locked drives", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - ALSA: hda/cs35l41: Fix firmware load work teardown", " - io_uring/rw: ensure reissue path is correctly handled for IOPOLL", " - io_uring/rw: preserve partial result for iopoll", " - Bluetooth: L2CAP: Fix not tracking outstanding TX ident", " - mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless", " host", " - ksmbd_vfs_rename(): vfs_path_parent_lookup() accepts ERR_PTR() as name", " - vfs: make LAST_XXX private to fs/namei.c", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " - HID: pidff: Fix missing blank lines after declarations", " - HID: pidff: Add missing spaces", " - HID: pidff: Rework pidff_upload_effect", " - HID: pidff: Use correct effect type in effect update", " - bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()", " - USB: iowarrior: fix use-after-free on disconnect race", " - crypto: atmel-sha204a - fail on hwrng registration error in probe path", " - btrfs: concentrate the error handling of submit_one_sector()", " - btrfs: remove folio parameter from ordered io related functions", " - btrfs: remove the COW fixup mechanism", " - slab: Introduce kmalloc_obj() and family", " - slab: Introduce kmalloc_flex() and family", " - add default_gfp() helper macro and use it in the new *alloc_obj()", " helpers", " - default_gfp(): avoid using the \"newfangled\" __VA_OPT__ trick", " - slab: recognize @GFP parameter as optional in kernel-doc", " - fscrypt: Fix key setup in edge case with multiple data unit sizes", " - fscrypt: Replace mk_users keyring with simple list", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is", " uninitialized", " - rtnetlink: Make per-netns RTNL dereference helpers to macro.", " - afs: Fix afs_atcell_get_link() to check if ws_cell is unset first", " - afs: Fix afs_dynroot_readdir() to not use the RCU read lock", " - udp_tunnel: fix deadlock in udp_tunnel_nic_set_port_priv()", " - i40e: drop udp_tunnel_get_rx_info() call from i40e_open()", " - ice: drop udp_tunnel_get_rx_info() call from ndo_open()", " - Bluetooth: L2CAP: Fix regressions caused by reusing ident", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " - perf: Reject exited events as group leaders", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - proc: Fix broken error paths for namespace links", " - Upstream stable to v6.6.145, v6.12.96, v6.12.97", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2026-53365", " - vsock/virtio: fix zerocopy completion for multi-skb sends", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two", " - x86/mm: Fix check/use ordering in switch_mm_irqs_off()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192)", " - debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING", " - debugobjects: Use LD_WAIT_CONFIG instead of LD_WAIT_SLEEP", " - debugobjects: Dont call fill_pool() in early boot hardirq context", " - ARM: group is_permission_fault() with is_translation_fault()", " - ARM: allow __do_kernel_fault() to report execution of memory faults", " - ARM: fix branch predictor hardening", " - RDMA/bnxt_re: zero shared page before exposing to userspace", " - selftests/bpf: Add test to ensure kprobe_multi is not sleepable", " - bpf: Remove mark_precise_scalar_ids()", " - selftests/bpf: Tests for per-insn sync_linked_regs() precision tracking", " - selftests/bpf: Update comments find_equal_scalars->sync_linked_regs", " - hv: utils: handle and propagate errors in kvp_register", " - Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs", " - phonet: Pass ifindex to fill_addr().", " - phonet: Pass net and ifindex to phonet_address_notify().", " - scripts/sorttable: Remove unused macro defines", " - scripts/sorttable: Remove unused write functions", " - scripts/sorttable: Remove unneeded Elf_Rel", " - scripts/sorttable: Have the ORC code use the _r() functions to read", " - scripts/sorttable: Make compare_extable() into two functions", " - scripts/sorttable: Convert Elf_Ehdr to union", " - scripts/sorttable: Replace Elf_Shdr Macro with a union", " - scripts/sorttable: Convert Elf_Sym MACRO over to a union", " - scripts/sorttable: Add helper functions for Elf_Ehdr", " - scripts/sorttable: Add helper functions for Elf_Shdr", " - scripts/sorttable: Add helper functions for Elf_Sym", " - scripts/sorttable: Use uint64_t for mcount sorting", " - scripts/sorttable: Move code from sorttable.h into sorttable.c", " - scripts/sorttable: Get start/stop_mcount_loc from ELF file directly", " - scripts/sorttable: Use a structure of function pointers for elf helpers", " - arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64", " - [Config] Set configs to sort mcount_loc at boot for arm64", " - scripts/sorttable: Have mcount rela sort use direct values", " - scripts/sorttable: Always use an array for the mcount_loc sorting", " - scripts/sorttable: Zero out weak functions in mcount_loc table", " - ftrace: Update the mcount_loc check of skipped entries", " - ftrace: Have ftrace pages output reflect freed pages", " - ftrace: Do not over-allocate ftrace memory", " - ftrace: Test mcount_loc addr before calling ftrace_call_addr()", " - ftrace: Check against is_kernel_text() instead of kaslr_offset()", " - scripts/sorttable: Use normal sort if theres no relocs in the mcount", " section", " - scripts/sorttable: Allow matches to functions before function entry", " - scripts/sorttable: Fix endianness handling in build-time mcount sort", " - file: add fput() cleanup helper", " - eventpoll: use hlist_is_singular_node() in __ep_remove()", " - Revert \"ptp: add testptp mask test\"", " - Bluetooth: btmtk: validate WMT event SKB length before struct access", " - Bluetooth: btmtk: accept too short WMT FUNC_CTRL events", " - batman-adv: tp_meter: keep unacked list in ascending ordered", " - batman-adv: tp_meter: initialize dup_acks explicitly", " - batman-adv: tp_meter: initialize dec_cwnd explicitly", " - batman-adv: tp_meter: avoid window underflow", " - batman-adv: tp_meter: fix fast recovery precondition", " - batman-adv: tp_meter: handle seqno wrap-around for fast recovery", " detection", " - batman-adv: tp_meter: add only finished tp_vars to lists", " - batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE", " - batman-adv: prevent ELP transmission interval underflow", " - batman-adv: tp_meter: initialize last_recv_time during init", " - batman-adv: ensure bcast is writable before modifying TTL", " - batman-adv: fix (m|b)cast csum after decrementing TTL", " - batman-adv: frag: ensure fragment is writable before modifying TTL", " - batman-adv: frag: avoid underflow of TTL", " - batman-adv: tp_meter: annotate last_recv_time access with", " READ/WRITE_ONCE", " - batman-adv: tp_meter: prevent parallel modifications of last_recv", " - batman-adv: tp_meter: handle overlapping packets", " - batman-adv: tt: don't merge change entries with different VIDs", " - batman-adv: tt: track roam count per VID", " - batman-adv: dat: prevent false sharing between VLANs", " - batman-adv: tvlv: enforce 2-byte alignment", " - batman-adv: tvlv: avoid race of cifsnotfound handler state", " - inet: add indirect call wrapper for getfrag() calls", " - err.h: use __always_inline on all error pointer helpers", " - wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S", " - wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor", " - wifi: rtw88: increase TX report timeout to fix race condition", " - wifi: iwlwifi: mvm: fix race condition in PTP removal", " - f2fs: fix to round down start offset of fallocate for pin file", " - f2fs: keep atomic write retry from zeroing original data", " - MIPS: DEC: Prevent initial console buffer from landing in XKPHYS", " - fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode", " - nfsd: check get_user() return when reading princhashlen", " - NFS: Prevent resource leak in nfs_alloc_server()", " - serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero", " - wifi: mt76: mt7921: avoid undesired changes of the preset regulatory", " domain", " - ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()", " - xfs: fix error returns in CoW fork repair", " - locking/mutex: Remove wakeups from under mutex::wait_lock", " - net: ipv6: Make udp_tunnel6_xmit_skb() void", " - Revert \"PCI: qcom: Advertise Hotplug Slot Capability with no Command", " Completion support\"", " - KVM: SEV: Ignore MMIO requests of length '0'", " - mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program", " - mtd: spi-nor: macronix: add support for mx66{l2, u1}g45g", " - LoongArch: Report dying CPU to RCU in stop_this_cpu()", " - MIPS: smp: report dying CPU to RCU in stop_this_cpu()", " - locking: rtmutex: Fix wake_q logic in task_blocks_on_rt_mutex", " - bonding: annotate data-races arcound churn variables", " - Upstream stable to v6.6.144, v6.12.95", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53389", " - net/tcp-ao: fix use-after-free of key in del_async path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53393", " - nfsd: reset write verifier on deferred writeback errors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53400", " - i2c: core: fix adapter registration race", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63806", " - KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with", " get_unaligned()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63940", " - KVM: SEV: Ignore Port I/O requests of length '0'", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53387", " - iio: light: veml6075: add bounds check to veml6075_it_ms index", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53070", " - sctp: disable BH before calling udp_tunnel_xmit_skb()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43216", " - net: Drop the lock in skb_may_tx_timestamp()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64244", " - drivers/base/memory: set mem->altmap after successful device", " registration", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53384", " - serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53390", " - ksmbd: fix out-of-bounds read in smb_check_perm_dacl()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53391", " - NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53397", " - nfsd: fix posix_acl leak on SETACL decode failure", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64245", " - fbdev: modedb: fix a possible UAF in fb_find_mode()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53403", " - fbdev: Fix fb_new_modelist to prevent null-ptr-deref in", " fb_videomode_to_var", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64246", " - power: reset: linkstation-poweroff: fix use-after-free in the", " linkstation_poweroff_init()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63794", " - KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64247", " - KVM: x86: hyper-v: Bound the bank index when querying sparse banks", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63795", " - 9p: avoid putting oldfid in p9_client_walk() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63796", " - ocfs2: reject oversized group bitmap descriptors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63797", " - rpmsg: char: Fix use-after-free on probe error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64249", " - fpga: region: fix use-after-free in child_regions_with_firmware()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63798", " - irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup", " on remove", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63801", " - tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63802", " - blk-cgroup: fix UAF in __blkcg_rstat_flush()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63803", " - hdlc_ppp: sync per-proto timers before freeing hdlc state", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63804", " - gfs2: fix use-after-free in gfs2_qd_dealloc", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63809", " - bpf: use kvfree() for replaced sysctl write buffer", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63812", " - f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63814", " - f2fs: validate ACL entry sizes in f2fs_acl_from_disk()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63817", " - f2fs: validate compress cache inode only when enabled", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63821", " - wifi: rtw88: usb: fix memory leaks on USB write failures", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63822", " - wifi: ath11k: fix warning when unbinding", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63823", " - keys: Pin request_key_auth payload in instantiate paths", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63824", " - KEYS: fix overflow in keyctl_pkey_params_get_2()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63826", " - fbdev: fix use-after-free in store_modes()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64254", " - NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG", " share BAR", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63827", " - apparmor: fix use-after-free in rawdata dedup loop", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63828", " - apparmor: mediate the implicit connect of TCP fast open sendmsg", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63830", " - net: skmsg: preserve sg.copy across SG transforms", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63831", " - mac802154: llsec: add skb_cow_data() before in-place crypto", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53361", " - af_unix: Set gc_in_progress to true in unix_gc().", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63833", " - ntfs3: reject direct userspace writes to reserved $LX* xattrs", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53366", " - ipv4: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53362", " - ipv6: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63834", " - batman-adv: tp_meter: restrict number of unacked list entries", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63835", " - batman-adv: v: prevent OGM aggregation on disabled hardif", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63836", " - batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63807", " - KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping", " level", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53381", " - virtiofs: fix UAF on submount umount", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53382", " - media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53383", " - ksmbd: reject non-VALID session in compound request branch", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53385", " - vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent", " vcs_write", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53388", " - fuse: re-lock request before replacing page cache folio", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53157", " - net: phonet: free phonet_device after RCU grace period", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53163", " - locking/rtmutex: Skip remove_waiter() when waiter is not enqueued", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2025-23131", " - dlm: prevent NPD when writing a positive value to event_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-46252", " - regulator: core: fix locking in regulator_resolve_supply() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52928", " - af_unix: Reject SIOCATMARK on non-stream sockets", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43010", " - bpf: Reject sleepable kprobe_multi programs at attach time", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53325", " - agp/amd64: Fix broken error propagation in agp_amd64_probe()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64188", " - net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64191", " - i2c: stub: Reject I2C block transfers with invalid length", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53327", " - debugobjects: Do not fill_pool() if pi_blocked_on", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52909", " - ip6_vti: set netns_immutable on the fallback device.", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53167", " - fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios", "" ], "package": "linux", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 11:03:24 +0200" }, { "cves": [ { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-146.146 -proposed tracker (LP: #2166353)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", "", " * Bluetooth fails to initialize due to a kernel NULL pointer error", " (LP: #2165873)", " - Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c", "", " * Dell Precision fails to shutdown when HDMI display is connected (22.04", " HWE) (LP: #2164507)", " - drm/i915/vbt: Add fields dedicated_external and dyn_port_over_tc", " - drm/i915/display: Handle dedicated external ports in", " intel_encoder_is_tc()", "", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", "", " * [SRU] HPE: Fix for UBSAN array-index-out-of-bounds (LP: #2161004)", " - x86/platform/uv: Fix UBSAN array-index-out-of-bounds", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough", " (LP: #2089306)", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Reboot machine with ext4 configured to data=journal could dump spurious", " call trace (LP: #2164716)", " - ext4: clear stale xarray tags on folios skipped during writeback", "", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", "", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796)", " - netfilter: bitwise: rename some boolean operation functions", " - netfilter: bitwise: add support for doing AND, OR and XOR directly", " - drm/fbdev-helper: Set and clear VGA switcheroo client from fb_info", " - arm64: io: Rename ioremap_prot() to __ioremap_prot()", " - Disable -Wattribute-alias for clang-23 and newer", " - netfilter: xt_NFQUEUE: prefer raw_smp_processor_id", " - drm/imx: Fix three kernel-doc warnings in dcss-scaler.c", " - pcnet32: stop holding device spin lock during napi_complete_done", " - net: Annotate sk->sk_write_space() for UDP SOCKMAP.", " - net: lan743x: permit VLAN-tagged packets up to configured MTU", " - net: fec: fix pinctrl default state restore order on resume", " - Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame()", " extension handling", " - Bluetooth: MGMT: Fix backward compatibility with userspace", " - ptp: vclock: Switch from RCU to SRCU", " - octeontx2-af: npc: Fix CPT channel mask in npc_install_flow", " - vxlan: vnifilter: send notification on VNI add", " - vxlan: vnifilter: fix spurious notification on VNI update", " - ipmi: Fix rcu_read_unlock to srcu_read_unlock in handle_read_event_rsp", " - time: Fix off-by-one in settimeofday() usec validation", " - tools/rv: Fix cleanup after failed trace setup", " - arm64: tlb: Allow XZR argument to TLBI ops", " - iomap: don't revert iov_iter on partially completed buffered writes", " - net/mlx4: avoid GCC 10 __bad_copy_from() false positive", " - r8152: handle the return value of usb_reset_device()", " - rds: mark snapshot pages dirty in rds_info_getsockopt()", " - net: mvpp2: Add metadata support for xdp mode", " - net: mvpp2: build skb from XDP-adjusted data on XDP_PASS", " - clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time", " - tracing/probes: Point the error offset correctly for eprobe argument", " error", " - mmc: litex_mmc: Use DIV_ROUND_UP for more accurate clock calculation", " - USB: serial: option: add usb-id for Dell Wireless DW5826e-m", " - ALSA: timer: Fix UAF at snd_timer_user_params()", " - drm/amd/display: Reject gpio_bitshift >= 32 in", " bios_parser_get_gpio_pin_info()", " - mm/damon/ops-common: call folio_test_lru() after folio_get()", " - ARM: socfpga: Fix OF node refcount leak in SMP setup", " - ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O", " - mptcp: fix retransmission loop when csum is enabled", " - mptcp: sockopt: check timestamping ret value", " - selftests: mptcp: add test for extra_subflows underflow on userspace PM", " - ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write", " - inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush", " - pidfd: refuse access to tasks that have started exiting harder", " - i2c: stm32f7: fix timing computation ignoring i2c-analog-filter", " - i2c: tegra: Fix NOIRQ suspend/resume", " - Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)", " - Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard", " - net/mlx5: Reorder completion before putting command entry in", " cmd_work_handler", " - net: mv643xx: fix OF node refcount", " - octeontx2-af: fix memory leak in rvu_setup_hw_resources()", " - mmc: core: Fix host controller programming for fixed driver type", " - mmc: litex_mmc: Set mandatory idle clocks before CMD0", " - mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC", " - mmc: sdhci: add signal voltage switch in sdhci_resume_host", " - slimbus: qcom-ngd-ctrl: fix OF node refcount", " - drm/amdgpu: restart the CS if some parts of the VM are still invalidated", " - fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling", " - driver core: reject devices with unregistered buses", " - mm/hugetlb: avoid false positive lockdep assertion", " - soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get()", " - ipmi:ssif: Remove unnecessary indention", " - ipmi:ssif: NULL thread on error", " - selftests: mptcp: drop nanoseconds width specifier", " - tty: serial: samsung: use u32 for register interactions", " - RDMA/umem: fix kernel-doc warnings", " - RDMA: Move DMA block iterator logic into dedicated files", " - arm64: cputype: Add NVIDIA Olympus definitions", " - arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU", " - mptcp: add-addr: always drop other suboptions", " - mptcp: fix missing wakeups in edge scenarios", " - Revert \"selftest/ptp: update ptp selftest to exercise the gettimex", " options\"", " - ARM: fix hash_name() fault", " - wifi: remove zero-length arrays", " - soc: qcom: ice: Return -ENODEV if the ICE platform device is not found", " - Bluetooth: ISO: Fix not using bc_sid as advertisement SID", " - octeontx2-pf: Fix NDC sync operation errors", " - octeontx2-af: Fix initialization of mcam's entry2target_pffunc field", " - ima: kexec: skip IMA segment validation after kexec soft reboot", " - ima: kexec: move IMA log copy from kexec load to execute", " - gpio: zynq: fix runtime PM leak on remove", " - writeback: Avoid contention on wb->list_lock when switching inodes", " - writeback: Fix use after free in inode_switch_wbs_work_fn()", " - xfrm: hold device only for the asynchronous decryption", " - KVM: VMX: Update SVI during runtime APICv activation", " - drm/xe: fix refcount leak in xe_range_fence_insert()", " - slimbus: qcom-ngd-ctrl: Fix up platform_driver registration", " - slimbus: qcom-ngd-ctrl: Fix probe error path ordering", " - slimbus: qcom-ngd-ctrl: Initialize controller resources in controller", " - slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership", " - slimbus: qcom-ngd-ctrl: Balance pm_runtime enablement for NGD", " - drm/amd/pm: fix smu13 power limit default/cap calculation", " - drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in", " set_soft_freq_limited_range", " - drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs", " - mailbox: Fix NULL message support in mbox_send_message()", " - vsock/virtio: fix skb overhead accounting to preserve full buf_alloc", " - net: introduce EXPORT_IPV6_MOD() and EXPORT_IPV6_MOD_GPL()", " - mptcp: pm: fix extra_subflows underflow on userspace PM subflow creation", " - vsock/virtio: fix skb overhead overflow on 32-bit builds", " - Upstream stable to v6.6.143, v6.12.94", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53132", " - vsock/virtio: fix potential unbounded skb queue", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53138", " - drm/amd/display: Bound VBIOS record-chain walk loops", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53140", " - drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53332", " - slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53156", " - nvmem: core: fix use-after-free bugs in error paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53202", " - accel/ivpu: Fix signed integer truncation in IPC receive", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53205", " - accel/ivpu: Add bounds checks for firmware log indices", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53210", " - tee: shm: fix shm leak in register_shm_helper()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-31663", " - xfrm: hold dev ref until after transport_finish NF_HOOK", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53220", " - netfilter: revalidate bridge ports", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53229", " - net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46203", " - spi: cadence-quadspi: fix unclocked access on unbind", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63871", " - Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53251", " - Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63869", " - wifi: mac80211: limit injected antenna index in", " ieee80211_parse_tx_radiotap", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53261", " - devlink: Release nested relation on devlink free", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53262", " - l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses", " - arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-45850", " - ipvs: skip ipv6 extension headers for csum checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53133", " - RDMA/umem: Fix truncation for block sizes >= 4G", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52908", " - RDMA: During rereg_mr ensure that REREG_ACCESS is compatible", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53199", " - hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53134", " - netfilter: nft_fib: fix stale stack leak via the OIFNAME register", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63883", " - serial: qcom_geni: fix kfifo underflow when flush precedes DMA", " completion IRQ", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64528", " - tty: serial: samsung: Remove redundant port lock acquisition in rx", " helpers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53329", " - drm/amd/display: Use krealloc_array() in dal_vector_reserve()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53135", " - drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53136", " - drm/amd/display: Clamp VBIOS HDMI retimer register count to array size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53137", " - drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53143", " - drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on", " GFX11", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53144", " - drm/amdkfd: fix NULL dereference in get_queue_ids()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53331", " - slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53146", " - thunderbolt: Limit XDomain response copy to actual frame size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53147", " - thunderbolt: Validate XDomain request packet size before type cast", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53148", " - thunderbolt: Clamp XDomain response data copy to allocation size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53149", " - thunderbolt: Bound root directory content to block size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53150", " - thunderbolt: Reject zero-length property entries in validator", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52929", " - sctp: stream: fully roll back denied add-stream state", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52917", " - sctp: diag: reject stale associations in dump_one path", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53154", " - mm/hugetlb: restore reservation on error in hugetlb folio copy paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53336", " - nvmem: layouts: onie-tlv: fix hang on unknown types", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53337", " - net: bonding: fix NULL pointer dereference in bond_do_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53158", " - misc: fastrpc: Fix NULL pointer dereference in rpmsg callback", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53159", " - misc: fastrpc: fix DMA address corruption due to find_vma misuse", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53160", " - misc: fastrpc: fix use-after-free race in fastrpc_map_create", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53161", " - misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52930", " - ipc/shm: serialize orphan cleanup with shm_nattch updates", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53339", " - i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53168", " - fuse: reject fuse_notify() pagecache ops on directories", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53177", " - bnxt_en: Fix NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53181", " - vsock/vmci: fix sk_ack_backlog leak on failed handshake", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53182", " - wifi: nl80211: reject oversized EMA RNR lists", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53183", " - mptcp: allow subflow rcv wnd to shrink", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63867", " - mptcp: close TOCTOU race while computing rcv_wnd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53343", " - ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53184", " - udp: clear skb->dev before running a sockmap verdict", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53185", " - zram: fix use-after-free in zram_bvec_write_partial()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53190", " - drm/virtio: fix dma_fence refcount leak on error in", " virtio_gpu_dma_fence_wait()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53194", " - USB: serial: kl5kusb105: fix bulk-out buffer overflow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53195", " - USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53196", " - USB: serial: io_ti: fix heap overflow in get_manuf_info()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52935", " - xfrm: espintcp: do not reuse an in-progress partial send", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53198", " - ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53356", " - drm/i915/gem: Fix phys BO pread/pwrite with offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53345", " - KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53208", " - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53209", " - Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53213", " - drm/vc4: fix krealloc() memory leak", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53347", " - drm/virtio: Fix driver removal with disabled KMS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43116", " - netfilter: ctnetlink: ensure safe access to master conntrack", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53214", " - ipv6: Fix a potential NPD in cleanup_prefix_route()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53217", " - net: mvpp2: sync RX data at the hardware packet offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53218", " - netfilter: nft_exthdr: fix register tracking for F_PRESENT flag", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52942", " - netfilter: nf_log: validate MAC header was set before dumping it", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53219", " - netfilter: x_tables: avoid leaking percpu counter pointers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53349", " - netfilter: nf_conntrack: destroy stale expectfn expectations on", " unregister", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52939", " - net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic", " completion", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53223", " - net: guard timestamp cmsgs to real error queue skbs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53227", " - net: openvswitch: fix possible kfree_skb of ERR_PTR", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53230", " - net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52947", " - net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53232", " - net: phy: clean the sfp upstream if phy probing fails", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53236", " - tcp: restrict SO_ATTACH_FILTER to priv users", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53350", " - ASoC: wm_adsp: Fix NULL dereference when removing firmware controls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53237", " - gpio: mvebu: fix NULL pointer dereference in suspend/resume", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53238", " - netlabel: validate unlabeled address and mask attribute lengths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53239", " - xfrm: policy: fix use-after-free on inexact bin in", " xfrm_policy_bysel_ctx()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46320", " - tap: free page on error paths in tap_get_user_xdp()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53242", " - ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked", " streams", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53352", " - signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53245", " - net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63870", " - ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53249", " - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53252", " - Bluetooth: fix memory leak in error path of hci_alloc_dev()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53253", " - Bluetooth: bnep: reject short frames before parsing", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53254", " - Bluetooth: RFCOMM: validate skb length in MCC handlers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53255", " - Bluetooth: MGMT: validate advertising TLV before type checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53256", " - Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63868", " - net: garp: fix unsigned integer underflow in garp_pdu_parse_attr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53353", " - hsr: Remove WARN_ONCE() in hsr_addr_is_self().", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53263", " - 6lowpan: fix off-by-one in multicast context address compression", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53264", " - net/sched: act_api: use RCU with deferred freeing for action lifecycle", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53265", " - dm cache policy smq: check allocation under invalidate lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53266", " - netfilter: bridge: make ebt_snat ARP rewrite writable", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53267", " - netfilter: nft_ct: bail out on template ct in get eval", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53268", " - netfilter: conntrack_irc: fix possible out-of-bounds read", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53269", " - netfilter: synproxy: add mutex to guard hook reference counting", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53270", " - ipvs: clear the svc scheduler ptr early on edit", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53273", " - tee: optee: prevent use-after-free when the client exits before the", " supplicant", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53274", " - net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53275", " - ipv6: mcast: Fix use-after-free when processing MLD queries", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52948", " - i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63898", " - USB: serial: mct_u232: fix memory corruption with small endpoint", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52910", " - bpf: Free reuseport cBPF prog after RCU grace period.", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43311", " - soc/tegra: pmc: Fix unsafe generic_handle_irq() call", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43240", " - x86/kexec: add a sanity check on previous kernel's ima kexec buffer", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-23346", " - arm64: io: Extract user memory type in ioremap_prot()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52944", " - ksmbd: fix FSCTL permission bypass by adding a permission check for", " FSCTL_SET_SPARSE", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64006", " - netfilter: nf_tables: fix dst corruption in same register operation", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547)", " - Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size", " - drm/v3d: Fix use-after-free of CPU job query arrays on error path", " - drm/v3d: Release indirect CSD GEM reference on CPU job free", " - xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit", " - net/sched: sch_sfb: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - bcache: fix uninitialized closure object", " - nfc: llcp: Fix use-after-free in llcp_sock_release()", " - nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()", " - xfrm: Check for underflow in xfrm_state_mtu", " - nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems", " - kunit: fix use-after-free in debugfs when using kunit.filter", " - netfilter: xt_cpu: prefer raw_smp_processor_id", " - vsock: keep poll shutdown state consistent", " - net: netlink: fix sending unassigned nsid after assigned one", " - net: netlink: don't set nsid on local notifications", " - net/smc: Do not re-initialize smc hashtables", " - net/iucv: fix locking in .getsockopt", " - scsi: core: Run queues for all non-SDEV_DEL devices from", " scsi_run_host_queues", " - ipv4: free net->ipv4.sysctl_local_reserved_ports after", " unregister_net_sysctl_table()", " - ALSA: pcm: oss: Fix setup list UAF on proc write error", " - ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors", " - gpio: mxc: fix irq_high handling", " - ethtool: rss: fix hkey leak when indir_size is 0", " - ASoC: codecs: simple-mux: Fix enum control bounds check", " - Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()", " - bonding: refuse to enslave CAN devices", " - ethtool: eeprom: add missing ethnl_ops_begin() / _complete() during", " fallback", " - ethtool: eeprom: add more safeties to EEPROM Netlink fallback", " - net/sched: Revert \"net/sched: Restrict conditions for adding duplicating", " netems to qdisc tree\"", " - net/handshake: Use spin_lock_bh for hn_lock", " - nvme-tcp: store negative errno in queue->tls_err", " - net/handshake: Pass negative errno through handshake_complete()", " - Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success", " - Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp", " - Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close", " - gpio: rockchip: convert bank->clk to devm_clk_get_enabled()", " - net: mana: Add NULL guards in teardown path to prevent panic on attach", " failure", " - sctp: fix race between sctp_wait_for_connect and peeloff", " - ipv6: fix possible infinite loop in rt6_fill_node()", " - ipv6: fix possible infinite loop in fib6_select_path()", " - net: skbuff: fix pskb_carve leaking zcopy pages", " - perf: Fix dangling cgroup pointer in cpuctx", " - batman-adv: tvlv: abort OGM send on tvlv append failure", " - batman-adv: tt: reject oversized local TVLV buffers", " - batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface", " - batman-adv: iv: recover OGM scheduling after forward packet error", " - batman-adv: tp_meter: avoid role confusion in tp_list", " - batman-adv: tp_meter: directly shut down timer on cleanup", " - batman-adv: tt: avoid empty VLAN responses", " - batman-adv: bla: avoid double decrement of bla.num_requests", " - media: rc: fix race between unregister and urb/irq callbacks", " - media: rc: ttusbir: fix inverted error logic", " - inet: frags: add inet_frag_queue_flush()", " - HID: core: Add printk_ratelimited variants to hid_warn() etc", " - drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register", " - drm/i915/psr: Read Intel DPCD workaround register", " - drm/dp: Add eDP 1.5 bit definition", " - drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used", " - phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X", " - batman-adv: tt: prevent TVLV entry number overflow", " - iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer", " - usb: typec: ucsi: ccg: reject firmware images without a ':' record", " header", " - usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload", " VDO", " - usb: typec: altmodes/displayport: validate count before reading Status", " Update VDO", " - usb: typec: wcove: don't write past struct pd_message in", " wcove_read_rx_buffer()", " - usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT", " - usb: typec: ucsi: validate connector number in ucsi_connector_change()", " - USB: serial: safe_serial: fix memory corruption with small endpoint", " - media: rc: igorplugusb: fix control request setup packet", " - Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free()", " - HID: quirks: Add ALWAYS_POLL quirk for SIGMACHIP USB mouse", " - Bluetooth: btusb: Allow firmware re-download when version matches", " - hpfs: fix a crash if hpfs_map_dnode_bitmap fails", " - auxdisplay: line-display: fix OOB read on zero-length message_store()", " - Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn", " - Bluetooth: HIDP: fix missing length checks in hidp_input_report()", " - Bluetooth: ISO: fix UAF in iso_recv_frame", " - Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock", " - Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync", " - Input: xpad - fix out-of-bounds access for Share button", " - parport: Fix race between port and client registration", " - USB: cdc-acm: Fix bit overlap and move quirk definitions to header", " - KVM: arm64: PMU: Preserve AArch32 counter low bits", " - KVM: SVM: Flush the current TLB when transitioning from xAVIC => x2AVIC", " - iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux", " - iio: adc: npcm: fix unbalanced clk_disable_unprepare()", " - iio: dac: max5821: fix return value check in powerdown sync", " - iio: dac: ad5686: fix input raw value check", " - iio: dac: ad5686: acquire lock when doing powerdown control", " - iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw", " - iio: gyro: itg3200: fix i2c read into the wrong stack location", " - iio: gyro: adis16260: fix division by zero in write_raw", " - iio: ssp_sensors: cancel delayed work_refresh on remove", " - iio: temperature: tsys01: fix broken PROM checksum validation", " - iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL", " - iio: light: cm3323: fix reg_conf not being initialized correctly", " - iio: buffer: hw-consumer: fix use-after-free in error path", " - USB: serial: omninet: fix memory corruption with small endpoint", " - usb: cdns3: gadget: fix request skipping after clearing halt", " - usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy", " acquisition failure", " - usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently", " leaks the runtime PM usage counter across bind/unbind cycles", " - usb: dwc2: Fix use after free in debug code", " - Input: elan_i2c - validate firmware size before use", " - wireguard: send: append trailer after expanding head", " - bpf: sockmap: fix tail fragment offset in bpf_msg_push_data", " - macsec: fix replay protection at XPN lower-PN wrap", " - ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params", " - ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().", " - ipv6: validate extension header length before copying to cmsg", " - xfrm: input: hold netns during deferred transport reinjection", " - ip6: vti: Use ip6_tnl.net in vti6_changelink().", " - HID: wacom: Fix OOB write in wacom_hid_set_device_mode()", " - iommu, debugobjects: avoid gcc-16.1 section mismatch warnings", " - nfc: hci: fix out-of-bounds read in HCP header parsing", " - xfrm: route MIGRATE notifications to caller's netns", " - xfrm: ah: use skb_to_full_sk in async output callbacks", " - ALSA: scarlett2: Fix 2i2 Gen 4 direct monitor gain on firmware 2417", " - netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without", " direction check", " - ASoC: qcom: q6asm-dai: close stream only when running", " - ASoC: qcom: q6asm-dai: do not set stream state in event and trigger", " callbacks", " - Input: xpad - add \"Nova 2 Lite\" from GameSir", " - Input: xpad - add support for ASUS ROG RAIKIRI II", " - ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops", " - Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem", " - Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490", " - comedi: comedi_test: fix check for valid scan_begin_src in", " waveform_ai_cmdtest()", " - comedi: comedi_test: Fix limiting of convert_arg in", " waveform_ai_cmdtest()", " - counter: Fix refcount leak in counter_alloc() error path", " - tty: serial: pch_uart: add check for dma_alloc_coherent()", " - usb: chipidea: core: convert ci_role_switch to local variable", " - usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval", " - USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub", " controllers", " - usb: storage: Add quirks for PNY Elite Portable SSD", " - usbip: vudc: Fix use after free bug in vudc_remove due to race condition", " - usb: usbtmc: check URB actual_length for interrupt-IN notifications", " - usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize", " - USB: serial: option: add MeiG SRM813Q", " - USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL", " - USB: serial: belkin_sa: validate interrupt status length", " - USB: serial: cypress_m8: validate interrupt packet headers", " - USB: serial: keyspan: fix missing indat transfer sanity check", " - USB: serial: mxuport: fix memory corruption with small endpoint", " - USB: serial: mct_u232: fix missing interrupt-in transfer sanity check", " - usb: gadget: uvc: hold opts->lock across XU walks in uvc_function_bind", " - usb: gadget: net2280: Fix double free in probe error path", " - usb: gadget: f_hid: fix device reference leak in hidg_alloc()", " - usb: gadget: composite: fix integer underflow in WebUSB GET_URL handling", " - usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports", " - usb: gadget: f_fs: copy only received bytes on short ep0 read", " - thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()", " - thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow", " - scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker", " - scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32", " - drm/hyperv: validate resolution_count and fix WIN8 fallback", " - drm/hyperv: validate VMBus packet size in receive callback", " - drm/i915: Fix potential UAF in TTM object purge", " - drm/amd/pm/si: Disregard vblank time when no displays are connected", " - serial: altera_jtaguart: handle uart_add_one_port() failures", " - serial: qcom-geni: fix UART_RX_PAR_EN bit position", " - serial: sh-sci: fix memory region release in error path", " - serial: zs: Fix swapped RI/DSR modem line transition counting", " - serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma", " - drm/amdkfd: fix NULL pointer bug in svm_range_set_attr", " - drm/amdkfd: fix a vulnerability of integer overflow in kfd debugger", " - drm/amdkfd: Check for pdd drm file first in CRIU restore path", " - serial: dz: Fix bootconsole message clobbering at chip reset", " - serial: dz: Fix bootconsole handover lockup", " - serial: dz: Convert to use a platform device", " - serial: zs: Fix bootconsole handover lockup", " - serial: zs: Switch to using channel reset", " - serial: zs: Convert to use a platform device", " - USB: serial: cypress_m8: fix memory corruption with small endpoint", " - USB: serial: digi_acceleport: fix memory corruption with small endpoints", " - xhci: tegra: Fix ghost USB device on dual-role port unplug", " - iommu: Skip PASID validation for devices without PASID capability", " - x86/boot: Disable stack protector for early boot code", " - rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg", " - rxrpc: Fix RESPONSE packet verification to extract skb to a linear", " buffer", " - serdev: Provide a bustype shutdown function", " - Bluetooth: hci_qca: Migrate to serdev specific shutdown function", " - Bluetooth: hci_qca: Convert timeout from jiffies to ms", " - ALSA: scarlett2: Return ENOSPC for out-of-bounds flash writes", " - ALSA: scarlett2: Allow flash writes ending at segment boundary", " - mm/memory: fix spurious warning when unmapping device-private/exclusive", " pages", " - platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery", " - net: hsr: defer node table free until after RCU readers", " - mptcp: pm: fix ADD_ADDR timer infinite retry on option space", " insufficient", " - ice: fix VF queue configuration with low MTU values", " - mptcp: cleanup fallback dummy mapping generation", " - mptcp: reset rcv wnd on disconnect", " - arm64: tlb: Flush walk cache when unsharing PMD tables", " - octeontx2-pf: avoid double free of pool->stack on AQ init failure", " - mptcp: introduce the mptcp_init_skb helper", " - mptcp: handle first subflow closing consistently", " - mptcp: do not drop partial packets", " - mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()", " - iio: chemical: scd30: Use guard(mutex) to allow early returns", " - iio: chemical: scd30: fix division by zero in write_raw", " - iio: dac: ad5686: fix ref bit initialization for single-channel parts", " - ALSA: firewire-motu: Protect register DSP event queue positions", " - usb: dwc3: xilinx: fix error handling in zynqmp init error paths", " - usb: musb: omap2430: Fix use-after-free in omap2430_probe()", " - usb: typec: ucsi: Check if power role change actually happened before", " handling", " - thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()", " - usb: typec: ucsi: Don't update power_supply on power role change if not", " connected", " - hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with", " pmbus_lock", " - hwmon: (pmbus/adm1266) serialize NVMEM blackbox read with pmbus_lock", " - hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock", " - mm: perform all memfd seal checks in a single place", " - mm/memfd: fix spelling and grammatical issues", " - memfd: deny writeable mappings when implying SEAL_WRITE", " - usb: core: Fix SuperSpeed root hub wMaxPacketSize", " - Upstream stable to v6.12.93", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43331", " - x86/kexec: Disable KCOV instrumentation after load_segments()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52943", " - net: skbuff: fix missing zerocopy reference in pskb_carve helpers", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53358", " - Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52923", " - ipc: limit next_id allocation to the valid ID range", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2025-68768", " - inet: frags: flush pending skbs in fqdir_pre_exit()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43303", " - mm/page_alloc: clear page->private in free_pages_prepare()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52934", " - batman-adv: tvlv: reject oversized TVLV packets", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52913", " - batman-adv: v: stop OGMv2 on disabled interface", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46322", " - tun: free page on build_skb failure in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46321", " - tun: free page on short-frame rejection in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52927", " - netfilter: ebtables: fix OOB read in compat_mtw_from_user", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43219", " - net: cpsw_new: Fix potential unregister of netdev that has not been", " registered yet", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-45930", " - net: mctp: ensure our nlmsg responses are initialised", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53080", " - net/sched: cls_fw: fix NULL dereference of \"old\" filters before change()", "", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Enable CONFIG_ARM64_ERRATUM_4118414", "", " * CVE-2025-10263", " - arm64: cputype: Add C1-Ultra definitions", " - arm64: cputype: Add C1-Premium definitions", "", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", "", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", "", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", "", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", "", " * CVE-2026-63886", " - scsi: target: iscsi: Validate CHAP_R length before base64 decode", "", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", "", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", "", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", "", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", "", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", "", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", "", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", "", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", "", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", "", " * CVE-2026-64000", " - net: hsr: fix potential OOB access in supervision frame handling", "", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", "", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", "", " * CVE-2026-53131", " - netfilter: require Ethernet MAC header before using eth_hdr()", "" ], "package": "linux", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:47:58 +0300" } ], "notes": "linux-headers-6.8.0-147 version '6.8.0-147.147' (source package linux version '6.8.0-147.147') was added. linux-headers-6.8.0-147 version '6.8.0-147.147' has the same source package name, linux, as removed package linux-headers-6.8.0-142. As such we can use the source package version of the removed package, '6.8.0-142.142', 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-headers-6.8.0-147-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-147.147 -proposed tracker (LP: #2168142)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026)", " - platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug", " - selftests/bpf: Add tests for ld_{abs,ind} failure path in subprogs", " - drm/virtio: fix deadlock in display_info_cb by removing hotplug from", " dequeue worker", " - mtd: mtdswap: remove debugfs stats file on teardown", " - seqlock: Cure some more scoped_seqlock() optimization fails", " - seqlock: Allow KASAN to fail optimizing", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/umem: Add support for creating pinned DMABUF umem with a given dma", " device", " - RDMA/umem: Introduce an option to revoke DMABUF umem", " - RDMA/umem: Add ib_umem_dmabuf_get_pinned_and_lock helper", " - RDMA/umem: Move umem dmabuf revoke logic into helper function", " - RDMA/umem: Add pinned revocable dmabuf import interface", " - RDMA/umem: Add helpers for umem dmabuf revoke lock", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - selftests/alsa: Fix memory leak in find_controls error path", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: cs42l43: Correct report for forced microphone jack", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - sched/vtime: Get rid of generic vtime_task_switch() implementation", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - can: j1939: fix lockless local-destination check", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - crypto: rsa-pkcs1pad: Don't WARN on an empty digest", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - wifi: ath11k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - wifi: ath12k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - ASoC: cs35l56: Don't use devres to unregister component", " - ASoC: cs35l56: Fix potential probe() deadlock", " - ASoC: cs35l56: Use complete_all() to signal init_completion", " - wifi: iwlwifi: mvm: validate SAR GEO response payload size", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - hwmon: (asus-ec-sensors) fix looping over banks while reading from EC", " - hwmon: (asus-ec-sensors) fix EC read intervals", " - hwmon: (asus-ec-sensors) add missed handle for ENOMEM", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - pds_core: yield the CPU while waiting for the adminq to drain", " - pds_core: order completion reads after the ownership check", " - pds_core: check for workqueue allocation failure", " - tls: device: push pending open record on splice EOF", " - selftest: af_unix: Add Kconfig file.", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - amt: make the head writable before rewriting the L2 header", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: dpaa: fix mode setting", " - iomap: correct the range of a partial dirty clear", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - net: stmmac: enable the MAC on link up for all supported speeds", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - ppp: use IFF_NO_QUEUE in virtual interfaces", " - ppp: convert to percpu netstats", " - ppp: enable TX scatter-gather", " - ppp: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: fix LAG recipe to profile association", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't", " at 0 (v2)", " - drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nxp: imx8-isi: Clean up already-initialized pipes on probe", " failure", " - media: nxp: imx8-isi: Fix missing v4l2_subdev_cleanup() in pipe init", " error path", " - media: nxp: imx8-isi: Fix scale factor calculation for hardware rounding", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vivid: add vivid_update_reduced_fps()", " - media: vpif_capture: fix OF node reference imbalance", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - LoongArch: Fix oops during single-step debugging", " - x86/boot/compressed: Disable jump tables", " - serial: sc16is7xx: implement gpio get_direction() callback", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - ice: use READ_ONCE() to access cached PHC time", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amd/display: Fix dcn32 DTB DTO update breaking live pixel rate", " sources", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - net: pcs: xpcs: fix SGMII state reading", " - bpf: drop bpf_lsm_getselfattr from hook list", " - udmabuf: Do not create malformed scatterlists", " - i2c: davinci: Unregister cpufreq notifier on probe failure", " - VFS/audit: introduce kern_path_parent() for audit", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - rxrpc: Pull out certain app callback funcs into an ops table", " - fbcon: Rename struct fbcon_ops to struct fbcon_par", " - fbcon: Use correct type for vc_resize() return value", " - rxrpc: Don't need barrier for ->tx_bottom and ->acks_hard_ack", " - rxrpc: Use irq-disabling spinlocks between app and I/O thread", " - rxrpc: Fix notification vs call-release vs recvmsg", " - rxrpc: Fix socket notification race", " - vduse: Use fixed 4KB bounce pages for non-4KB page size", " - vduse: remove unused vaddr parameter of vduse_domain_free_coherent", " - vduse: take out allocations from vduse_dev_alloc_coherent", " - octeontx2: Annotate mmio regions as __iomem", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - fbdev/efifb: Replace references to global screen_info by local pointer", " - ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable()", " - ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe()", " - ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb", " - ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - netfilter: nft_set_pipapo: use GFP_KERNEL for insertions", " - netfilter: nft_set_pipapo: move prove_locking helper around", " - netfilter: nft_set_pipapo: make pipapo_clone helper return NULL", " - netfilter: nft_set_pipapo: prepare walk function for on-demand clone", " - netfilter: nft_set_pipapo: merge deactivate helper into caller", " - netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone", " - netfilter: nft_set_pipapo: move cloning of match info to insert/removal", " path", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_tables: Remove unused nft_reduce_is_readonly()", " - netfilter: nf_tables: remove register tracking infrastructure", " - NFSD: pass nfsd_file to nfsd_iter_read()", " - sunrpc: allocate a separate bvec array for socket sends", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - dma: dw-edma: Fix build warning in dw_edma_pcie_probe()", " - dmaengine: dw-edma: Fix confusing cleanup.h syntax", " - platform/x86: dell-smbios: Move request functions for reuse", " - i2c: imx: separate atomic, dma and non-dma use case", " - nfs: remove dead code for the old swap over NFS implementation", " - ovl: use linked upper dentry in copy-up tmpfile", " - bootconfig: do not put quotes on cmdline items unless necessary", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - rxrpc: Disable IRQ, not BH, to take the lock for ->attend_link", " - netfilter: nft_quota: use atomic64_xchg for reset", " - soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE", " - wifi: cfg80211: pass net_device to .set_monitor_channel", " - wifi: cfg80211: define and use wiphy guard", " - wifi: cfg80211: derive S1G beacon TSF from S1G fields", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - smb: move some duplicate definitions to common/cifsglob.h", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - wifi: mt76: mt7925: extend mt7925_mcu_bss_he_tlv for per-link BSS", " - ovl: fix trusted xattr escape prefix matching", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - dpll: add clock quality level attribute and op", " - net/mlx5: DPLL, Add clock quality level op implementation", " - net/mlx5: Remove newline at the end of a netlink error message", " - net/mlx5: Refactor EEPROM query error handling to return status", " separately", " - octeontx2-pf: tc: fix egress ratelimiting", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm/displayid: move drm_displayid.h to drm_displayd_internal.h", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - ALSA: timer: drain a slave's callback before its master detaches it", " - ALSA: timer: don't re-enter an instance callback that is still running", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - sysctl: treewide: constify ctl_table_header::ctl_table_arg", " - ceph: fix refcount leak in ceph_readdir()", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - net: move skb_gro_receive_list from udp to core", " - net: add pskb_may_pull() to skb_gro_receive_list()", " - vsock/virtio: collapse receive queue under memory pressure", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - xfs: add an explicit owner field to xfs_da_args", " - xfs: factor out xfs_attr3_leaf_init", " - xfs: don't replace the wrong part of the cow fork", " - rxrpc: Fix CPU time starvation in I/O thread", " - ASoC: mediatek: mt8183-afe-pcm: Shorten memif_data table using macros", " - ASoC: mediatek: mt8183-afe-pcm: Support >32 bit DMA addresses", " - tcp: Decrement tcp_md5_needed static branch", " - nvmet: Introduce nvmet_req_transfer_len()", " - block: add helper add_disk_final()", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections", " - Bluetooth: hci_core: Fix not accounting for BIS/CIS/PA links separately", " - afs: Improve server refcount/active count tracing", " - afs: Make afs_lookup_cell() take a trace note", " - afs: Drop the net parameter from afs_unuse_cell()", " - rxrpc: Allow the app to store private data on peer structs", " - afs: Use the per-peer app data provided by rxrpc", " - afs: Fix afs_server ref accounting", " - afs: Simplify cell record handling", " - afs: Fix dynamic lookup to fail on cell lookup failure", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - lib/string_choices: Add str_plural() helper", " - USB: gadget: Use str_enable_disable-like helpers", " - usb: musb: omap2430: clean up probe error handling", " - net/mlx5e: Fix NULL pointer dereference in ioctl module EEPROM query", " - rxrpc: Fix locking issues with the peer record hash", " - wifi: nl80211: fix nl80211_start_radar_detection return value", " - afs: Set vllist to NULL if addr parsing fails", " - dpll: fix clock quality level reporting", " - afs: Fix delayed allocation of a cell's anonymous key", " - afs: handle CB.InitCallBackState3 requests without a server record", " - Bluetooth: hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK", " - Bluetooth: hci_conn: Fix not cleaning up Broadcaster/Broadcast Source", " - Bluetooth: hci_conn: Remove redundant memset after kzalloc", " - Bluetooth: hci_conn: Fix not cleaning up PA_LINK connections", " - Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()", " - afs: Fix uninit var in afs_alloc_anon_key()", " - Upstream stable to v6.6.148, v6.12.101", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72168", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72213", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72244", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53078", " - bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2025-40098", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_get_acpi_mute_state()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68372", " - usb: core: port: Deattach Type-C connector on component unbind", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72175", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45901", " - netfilter: nf_tables: revert commit_mutex usage in reset path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45897", " - netfilter: nft_counter: serialize reset with spinlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72015", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72017", " - net: macb: drop in-flight Tx SKBs on close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72030", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72023", " - octeontx2-pf: fix SQB pointer leak on init failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72040", " - ipmi: fix refcount leak in i_ipmi_request()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72045", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72062", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72051", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72070", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72142", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72147", " - dmaengine: dw-edma-pcie: Reject devices without driver data", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72254", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72253", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72260", " - ASoC: mediatek: mt8192: Check runtime resume during probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72305", " - VDUSE: avoid leaking information to userspace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64205", " - i2c: i801: fix hardware state machine corruption in error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64280", " - fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72146", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72124", " - can: isotp: serialize TX state transitions under so->rx_lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72125", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72115", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72117", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72116", " - can: bcm: fix stale rx/tx ops after device removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72113", " - can: bcm: add missing device refcount for CAN filter removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72114", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72119", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72118", " - can: bcm: fix CAN frame rx/tx statistics", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72121", " - can: bcm: add locking when updating filter and timer values", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53090", " - bpf: Fix ld_{abs,ind} failure path analysis in subprogs", "", " * test_vxlan_vnifiltering.sh from ubuntu_kselftests_net failed on linux-", " oem-6.8 (with ipv6 default rdst) (LP: #2071590)", " - selftests: net: use slowwait to make sure IPv6 setup finished", "", " * ubuntu_bpf failed to build in noble (error: redefinition of", " 'stack_load_preserves_const_precision') (LP: #2160493)", " - SAUCE: Revert \"selftests/bpf: validate fake register spill/fill", " precision backtracking logic\"", "", " * CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", "", " * Backport: \"mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios\"", " (LP: #2162917)", " - mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios", "", " * qrtr: ns: node limit of 64 breaks QRTR routing on large multi-node", " deployments (LP: #2165140)", " - net: qrtr: ns: Raise node count limit to 512", "", " * [UBUNTU 24.04] kernel: CPU hotplug unsupported by CPUMF (LP: #2165732)", " - s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks", "", " * CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", "", " * CVE-2025-38563", " - perf/core: Prevent VMA split of buffer mappings", "", " * CVE-2025-38565", " - perf/core: Exit early on perf_mmap() fail", "", " * CVE-2025-38187", " - drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()", "", " * CVE-2025-38069", " - PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops", "", " * CVE-2025-40014", " - objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()", "", " * CVE-2025-21985", " - drm/amd/display: Fix out-of-bound accesses", "", " * CVE-2024-56552", " - drm/xe/guc_submit: fix race around suspend_pending", "", " * CVE-2025-21687", " - vfio/platform: check the bounds of read/write syscalls", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237)", " - ext4: fix fd leak in EXT4_IOC_MOVE_EXT cross-sb validation", " - mm: refactor mm_access() to not return NULL", " - Upstream stable to v6.6.146, v6.12.98, v6.6.147, v6.12.99, v6.12.100", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237) //", " CVE-2026-64560", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995)", " - bpf, arm64: Reject out-of-range B.cond targets", " - nfsd: release layout stid on setlease failure", " - Bluetooth: btmtk: apply the common btmtk_fw_get_filename", " - Bluetooth: btmtk: Fix failed to send func ctrl for MediaTek devices.", " - Bluetooth: btmtk: Fix wait_on_bit_timeout interruption during shutdown", " - userfaultfd: gate must_wait writability check on pte_present()", " - perf: Fix dangling cgroup pointer in cpuctx backport", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error", " - device property: initialize the remaining fields of fwnode_handle in", " fwnode_init()", " - f2fs: validate orphan inode entry count", " - f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode", " - f2fs: fix potential deadlock in f2fs_balance_fs()", " - f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()", " - f2fs: fix listxattr handling of corrupted xattr entries", " - block: Avoid mounting the bdev pseudo-filesystem in userspace", " - i2c: core: fix irq domain leak on adapter registration failure", " - i2c: core: fix hang on adapter registration failure", " - i2c: core: fix NULL-deref on adapter registration failure", " - i2c: core: fix adapter debugfs creation", " - fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()", " - NFSv4/flexfiles: reject zero filehandle version count", " - locking/rtmutex: Make sure we wake anything on the wake_q when we", " release the lock->wait_lock", " - bonding: fix xfrm offload feature setup on active-backup mode", " - mm/vmscan: flush deferred TLB before freeing large folios", " - perf trace beauty fcntl: Fix build with older kernel headers", " - ACPI: CPPC: Suppress UBSAN warning caused by field misuse", " - ACPI: NFIT: core: Fix possible NULL pointer dereference", " - perf/core: Detach event groups during remove_on_exec", " - arm64: sysreg: Add layout for ID_AA64MMFR4_EL1", " - virtio_net: Support dynamic rss indirection table size", " - LoongArch: Add PIO for early access before ACPI PCI root register", " - usb: gadget: function: rndis: add length check to response query", " - usb: gadget: function: rndis: add length check for header", " - iio: accel: bmc150: clamp the device-reported FIFO frame count", " - iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error", " - iio: adc: lpc32xx: Initialize completion before requesting IRQ", " - iio: adc: ti-ads124s08: Return reset GPIO lookup errors", " - iio: chemical: scd30: Cleanup initializations and fix sign-extension bug", " - iio: event: Fix event FIFO reset race", " - iio: gyro: bmg160: bail out when bandwidth/filter is not in table", " - iio: gyro: bmg160: wait full startup time after mode change at probe", " - iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ", " - iio: imu: st_lsm6dsx: deselect shub page before reading whoami", " - iio: light: al3010: fix incorrect scale for the highest gain range", " - iio: light: gp2ap002: fix runtime PM leak on read error", " - iio: light: opt3001: fix missing state reset on timeout", " - iio: light: tsl2591: return actual error from probe IRQ failure", " - iio: light: veml6030: fix channel type when pushing events", " - iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call", " - iio: temperature: ltc2983: Fix reinit_completion() called after", " conversion start", " - ALSA: virtio: Add missing 384 kHz PCM rate mapping", " - ALSA: ymfpci: check snd_ctl_new1() return value", " - ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input", " parser", " - ALSA: cmipci: check snd_ctl_new1() return value", " - ALSA: es1938: check snd_ctl_new1() return value", " - ALSA: firewire: isight: bound the sample count to the packet payload", " - ALSA: gus: check snd_ctl_new1() return value", " - ALSA: ice1712: check snd_ctl_new1() return value", " - ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()", " - ALSA: usb-audio: avoid kobject path lookup in DualSense match", " - ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()", " - ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch", " put callbacks", " - ALSA: usb-audio: Update Babyface Pro control caches only after", " successful writes", " - ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful", " writes", " - vfio/pci: Use a private flag to prevent power state change with VFs", " - vfio/pci: Latch disable_idle_d3 per device", " - vfio/pci: Release the VGA arbiter client on register_device() failure", " - vfio/pci: Fix racy bitfields and tighten struct layout", " - vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc", " - Bluetooth: btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB", " - Bluetooth: btusb: fix use-after-free on registration failure", " - Bluetooth: btusb: fix use-after-free on marvell probe failure", " - Bluetooth: btusb: fix wakeup source leak on probe failure", " - binder: fix UAF in binder_thread_release()", " - binder: fix UAF in binder_free_transaction()", " - usb: xhci: Fix sleep in atomic context in xhci_free_streams()", " - PCI: altera: Do not dispose parent IRQ mapping", " - mm/damon/ops-common: handle extreme intervals in damon_hot_score()", " - netfilter: ipset: fix race between dump and ip_set_list resize", " - virtio-mmio: fix device release warning on module unload", " - hwrng: virtio: clamp device-reported used.len at copy_data()", " - USB: chaoskey: Fix slab-use-after-free in chaoskey_release()", " - usb: dwc3: run gadget disconnect from sleepable suspend context", " - 6lowpan: fix NHC entry use-after-free on error path", " - tipc: fix out-of-bounds read in broadcast Gap ACK blocks", " - staging: vme_user: bound slave read/write to the kern_buf size", " - smb: client: restrict implied bcc[0] exemption to responses without data", " area", " - staging: vme_user: fix location monitor leak in fake bridge", " - staging: vme_user: fix location monitor leak in tsi148 bridge", " - media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe", " - staging: media: atomisp: reduce load_primary_binaries() stack usage", " - staging: rtl8723bs: fix heap buffer overflow in", " rtw_cfg80211_set_wpa_ie()", " - staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()", " - staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop", " - staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop", " - staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and", " join_cmd_hdl()", " - staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop", " - staging: rtl8723bs: fix OOB write in HT_caps_handler()", " - crypto: amlogic - avoid double cleanup in meson_crypto_probe()", " - ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then", " SMB2_CANCEL", " - net: af_key: initialize alg_key_len for IPComp states", " - audit: Fix data races of skb_queue_len() readers on audit_queue", " - Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete", " - debugobjects: Plug race against a concurrent OOM disable", " - fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns", " - NTB: epf: Avoid calling pci_irq_vector() from hardirq context", " - io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item", " - ipv4: igmp: remove multicast group from hash table on device destruction", " - net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes", " - mfd: cros_ec: Delay dev_set_drvdata() until probe success", " - mm: shrinker: fix NULL pointer dereference in debugfs", " - netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump", " - f2fs: bound i_inline_xattr_size for non-inline-xattr inodes", " - drm/amd: Fix set but not used warnings", " - apparmor: advertise the tcp fast open fix is applied", " - nfsd: move name lookup out of nfsd4_list_rec_dir()", " - nfsd: change nfs4_client_to_reclaim() to allocate data", " - arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative", " - arm64: Fix early handling of FEAT_E2H0 not being implemented", " - KVM: arm64: Initialize HCR_EL2.E2H early", " - arm64: Revamp HCR_EL2.E2H RES1 detection", " - arm64: sysreg: Correct sign definitions for EIESB and DoubleLock", " - iio: adc: spear: Initialize completion before requesting IRQ", " - iio: imu: inv_icm42600: fix timestamp clock period by using lower value", " - ALSA: usb-audio: Roll back quirk control caches on write errors", " - usb: typec: tcpci_rt1711h: unregister TCPCI port with devres", " - gpio: eic-sprd: use raw_spinlock_t in the irq startup path", " - netfilter: ebtables: module names must be null-terminated", " - netfilter: ebtables: terminate table name before find_table_lock()", " - Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()", " - Bluetooth: bnep: pin L2CAP connection during netdev registration", " - Bluetooth: btnxpuart: Fix out-of-bounds firmware read in", " nxp_recv_fw_req_v3()", " - Bluetooth: fix UAF in bt_accept_dequeue()", " - Bluetooth: L2CAP: validate option length before reading conf opt value", " - fs/ntfs3: fsync files by syncing parent inodes", " - fs/ntfs3: zero-fill folios beyond i_valid in ntfs_read_folio()", " - fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()", " - coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer()", " - smb/client: Fix error code in smb2_aead_req_alloc()", " - ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE", " - ksmbd: add a permission check for FSCTL_SET_ZERO_DATA", " - ksmbd: serialize QUERY_DIRECTORY requests per file", " - ksmbd: require source read access for duplicate extents", " - ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock", " cancellation", " - ksmbd: add a WRITE_DAC/WRITE_OWNER check to SMB2 SET_INFO SECURITY", " - ksmbd: run set info with opener credentials", " - ksmbd: enforce FILE_READ_ATTRIBUTES on SMB_FIND_FILE_POSIX_INFORMATION", " - ksmbd: add per-handle permission check to FILE_LINK_INFORMATION", " - ksmbd: use opener credentials for delete-on-close", " - smb: client: fix query directory replay double-free", " - smb: client: fix query_info() replay double-free", " - smb: client: fix double-free in SMB2_ioctl() replay", " - smb: client: fix change notify replay double-free", " - smb: client: fix double-free in SMB2_flush() replay", " - smb: client: fix double-free in SMB2_open() replay", " - smb: client: fix double-free in SMB2_close() replay", " - smb: client: Fix next buffer leak in receive_encrypted_standard()", " - smb: client: use unaligned reads in parse_posix_ctxt()", " - smb: client: harden POSIX SID length parsing", " - smb: client: mask server-provided mode to 07777 in modefromsid", " - OPP: of: Fix potential memory leak in opp_parse_supplies()", " - firmware_loader: fix device reference leak in firmware_upload_register()", " - cpufreq: intel_pstate: Sync policy->cur during CPU offline", " - sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT", " - cpufreq: Fix hotplug-suspend race during reboot", " - cpufreq: pcc: fix use-after-free and double free in _OSC evaluation", " - posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path", " - clocksource/drivers/timer-tegra186: Fix support for multiple watchdog", " instances", " - X.509: Fix validation of ASN.1 certificate header", " - tools/mm/slabinfo: Fix trace disable logic inversion", " - tools/mm/slabinfo: fix total_objects attribute name", " - HID: wacom: stop hardware after post-start probe failures", " - HID: letsketch: fix UAF on inrange_timer at driver unbind", " - HID: lg-g15: cancel pending work on remove to fix a use-after-free", " - HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte", " reads", " - hfs/hfsplus: zero-initialize buffer in hfs_bnode_read", " - nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers", " - media: mtk-jpeg: cancel workqueue on release for supported platforms", " only", " - xfs: use null daddr for unset first bad log block", " - xfs: fix unreachable BIGTIME check in dquot flush validation", " - bpf: Reject fragmented frames in devmap", " - bpf: Restore sysctl new-value from 1 to 0", " - net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()", " - usb: cdc_acm: Add quirk for Uniden BC125AT scanner", " - usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()", " - USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub", " - usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()", " - usb: free iso schedules on failed submit", " - usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler", " - usb: gadget: udc: Fix use-after-free in gadget_match_driver", " - usb: gadget: f_printer: take kref only for successful open", " - USB: idmouse: fix use-after-free on disconnect race", " - USB: ldusb: fix use-after-free on disconnect race", " - USB: iowarrior: fix use-after-free on disconnect", " - USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD", " - USB: legousbtower: fix use-after-free on disconnect race", " - usb: sl811-hcd: disable controller wakeup on remove", " - USB: storage: include US_FL_NO_SAME in quirks mask", " - USB: misc: uss720: unregister parport on probe failure", " - usb: mtu3: unmap request DMA on queue failure", " - USB: serial: keyspan_pda: fix information leak", " - USB: serial: option: add Telit Cinterion FE990D50 compositions", " - USB: serial: digi_acceleport: fix broken rx after throttle", " - USB: serial: digi_acceleport: fix hard lockup on disconnect", " - USB: serial: digi_acceleport: fix write buffer corruption", " - USB: ulpi: fix memory leak on registration failure", " - USB: usb-storage: ene_ub6250: restore media-ready check", " - usbip: tools: support SuperSpeedPlus devices", " - usbip: vudc: fix NULL deref in vep_dequeue()", " - usb: typec: anx7411: use devm_pm_runtime_enable()", " - usb: typec: class: drop PD lookup reference", " - usb: typec: tcpm: Validate SVID index in svdm_consume_modes()", " - usb: typec: ucsi: Invert DisplayPort role assignment", " - usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt", " mode", " - usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove", " - usb: typec: ucsi: cancel pending work on system suspend", " - iio: temperature: ltc2983: Fix n_wires default bypassing rotation check", " - PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining", " - udf: validate free block extents against the partition length", " - udf: validate VAT header length against the VAT inode size", " - udf: validate sparing table length as an entry count, not a byte count", " - hwrng: jh7110 - fix refcount leak in starfive_trng_read()", " - dm-ioctl: report an error if a device has no table", " - nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace", " disks", " - btrfs: do not trim a device which is not writeable", " - partitions: aix: bound the pp_count scan to the ppe array", " - isofs: bound Rock Ridge symlink components to the SL record", " - crypto: af_alg - Remove zero-copy support from skcipher and aead", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps again", " - crypto: ecc - Fix carry overflow in vli multiplication", " - crypto: pcrypt - restore callback for non-parallel fallback", " - crypto: drbg - Fix returning success on failure in CTR_DRBG", " - crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels", " - crypto: drbg - Fix the fips_enabled priority boost", " - crypto: qat - validate RSA CRT component lengths", " - crypto: talitos - use dma_sync_single_for_cpu() before reading", " descriptor header", " - crypto: talitos - add chaining of arbitrary number of descriptor for the", " SEC1", " - crypto: talitos - move dma unmapping code in flush_channel() into a", " standalone dma_unmap_request() function", " - crypto: talitos - move dma mapping code in talitos_submit() into a", " standalone dma_map_request() function", " - crypto: talitos - move code in current_desc_hdr() into a standalone", " function", " - crypto: talitos/hash - prepare SEC1 descriptor chaining, remove", " additional descriptor", " - crypto: talitos/hash - use descriptor chaining for SEC1 instead of", " workqueue", " - crypto: talitos/hash - drop workqueue mechanism for SEC1", " - crypto: talitos/hash - rename first_desc/last_desc to", " first_request/last_request", " - crypto: talitos/hash - remove useless wrapper", " - crypto: talitos/hash - fix SEC2 64k - 1 ahash request limitation", " - arm64: fpsimd: Fix type mismatch in sme_{save,load}_state()", " - spi: fsl-lpspi: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - spi: fsl-lpspi: terminate the RX channel on TX prepare failure path", " - EDAC/i10nm: Don't fail probing if ADXL is missing", " - watchdog: apple: Add \"apple,t8103-wdt\" compatible", " - tracing: Prevent out-of-bounds read in glob matching", " - NFSv4: include MAY_WRITE in open permission mask for O_TRUNC", " - module: decompress: check return value of module_extend_max_pages()", " - exfat: bound uniname advance in exfat_find_dir_entry()", " - NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()", " - KVM: VMX: Refresh GUEST_PENDING_DBG_EXCEPTIONS.BS on all injected #DBs", " - KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest", " mode", " - udmabuf: fix DMA direction mismatch in release_udmabuf()", " - i2c: core: fix adapter deregistration race", " - i2c: mpc: Fix timeout calculations", " - i2c: stm32f7: truncate clock period instead of rounding it", " - Input: synaptics-rmi4 - unregister function handlers on physical driver", " registration failure", " - Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count", " - Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count", " - Input: elan_i2c - prevent division by zero and arithmetic underflow", " - Input: goodix - clamp the device-reported contact count", " - Input: iforce - bound the device-reported force-feedback effect index", " - Input: mms114 - fix touch indexing for MMS134S and MMS136", " - Input: touchwin - reset the packet index on every complete packet", " - Input: mms114 - reject an oversized device packet size", " - Input: maplemouse - fix NULL pointer dereference in open()", " - Input: mms114 - fix multi-touch slot corruption", " - Input: maple_keyb - set driver data before registering input device", " - Input: maplemouse - set driver data before registering input device", " - Input: maplecontrol - set driver data before registering input device", " - RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", " - fuse: fix device node leak in cuse_process_init_reply()", " - fuse: re-lock request before returning from fuse_ref_folio()", " - smb: client: reject overlapping data areas in SMB2 responses", " - xfs: fail recovery on a committed log item with no regions", " - xfs: resample the data fork mapping after cycling ILOCK", " - smb/server: do not require delete access for non-replacing links", " - sched/fair: Only update stats for allowed CPUs when looking for dst", " group", " - KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU", " - KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove CRYPTO_DEV_SUN4I_SS_PRNG", " - crypto: crypto4xx - Remove ahash-related code", " - bpf: Support for hardening against JIT spraying", " - x86/bugs: Enable IBPB flush on BPF JIT allocation", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix sequence number when no EOF", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - dt-bindings: power: imx93: Add MIPI PHY power domain", " - serial: msm: Disable DMA for kernel console UART", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: Fix further netns teardown to cancel the preallocation charger", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/amdgpu: fix integer overflow in amdgpu_gem_align_pitch()", " - drm/radeon: fix integer overflow in radeon_align_pitch()", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " - libbpf: Report error when a negative kprobe offset is specified", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg", " warning", " - wifi: cfg80211: fix grammar in MLO group key error message", " - arm64: tegra: Fix Tegra234 MGBE PTP clock", " - dt-bindings: pinctrl: nvidia,tegra234: Add missing required block", " - drm/amdkfd: Validate CRIU-restored IDs before idr_alloc", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sama5d4_wdt: Fix WDDIS detection on SAM9X60 and SAMA7G5", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - media: v4l2-common: Add YUV24 format info", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " - dlm: fix add msg handle in send_queue ordered", " - nilfs2: fix backing_dev_info reference leak", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - evm: terminate and bound the evm_xattrs read buffer", " - thermal: hwmon: Fix critical temperature attribute removal", " - clk: scpi: Unregister child clock providers on remove", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - spi: hisi-kunpeng: Use dev_err_probe() for host registration failure", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/srpt: fix integer overflow in immediate data length check", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - driver core: Use mod_delayed_work to prevent lost deferred probe work", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - bus: sunxi-rsb: Always check register address validity", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: seq: midi: Serialize output teardown with event_input", " - pinctrl: cs42l43: Fix polarity on debounce", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " - drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X", " client is registered", " - drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove", " - gpu: host1x: Allow entries in BO caches to be freed", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - gpu: host1x: Fix iommu_map_sgtable() return value check", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Harden parse_vma_segs() path parsing", " - libbpf: Fix UAF in strset__add_str()", " - dax/kmem: account for partial discontiguous resource upon removal", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - rpmsg: use generic driver_override infrastructure", " - md/raid10: reset read_slot when reusing r10bio for discard", " - RDMA/siw: bound Read Response placement to the RREAD length", " - block: skip sync_blockdev() on surprise removal in bdev_mark_dead()", " - crypto: algif_skcipher - force synchronous processing", " - crypto: crypto4xx - Remove insecure and unused rng_alg", " - crypto: hisi-trng - Remove crypto_rng interface", " - bpf: Restrict JIT predictor flush to cBPF", " - bpf: Skip redundant IBPB in pack allocator", " - bpf: Prefer packs that won't trigger an IBPB flush on allocation", " - bpf: Prefer dirty packs for eBPF allocations", " - clk: scmi: Fix clock rate rounding", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - bitops: use common function parameter names", " - media: rockchip: rga: fix too small buffer size", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - scsi: ufs: Fix wrong value printed in unexpected UPIU response case", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " - mm/fake-numa: fix under-allocation detection in uniform split", " - ext2: fix ignored return value of generic_write_sync()", " - sched: restore timer_slack_ns when resetting RT policy on fork", " - lib/test_meminit: use && for bools", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: reject FITRIM ranges shorter than a cluster", " - ocfs2/dlm: require a ref for locking_state debugfs open", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - bpf: Check tail zero of bpf_prog_info", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - wifi: wcn36xx: fix heap overflow from oversized firmware HAL response", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " - wifi: wcn36xx: fix OOB read from short trigger BA firmware response", " - ALSA: seq: Fix partial userptr event expansion", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - scsi: target: Fix hexadecimal CHAP_I handling", " - scsi: target: Remove tcm_loop target reset handling", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " - hwspinlock: qcom: avoid uninitialized struct members", " - sched/fair: Fix cpu_util runnable_avg arithmetic", " - wifi: mt76: fix argument to ieee80211_is_first_frag()", " - wifi: mt76: mt7915: fix potential tx_retries underflow", " - wifi: mt76: mt7921: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - spi: meson-spifc: fix runtime PM leak on remove", " - ASoC: codecs: aw88261: fix incorrect masks for boost regs", " - vduse: hold vduse_lock across IDR lookup in open path", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " - vduse: Requeue failed read to send_list head", " - vhost/net: complete zerocopy ubufs only once", " - tools/virtio: check mmap return value in vringh_test", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - bonding: 3ad: fix mux port state on oper down", " - ext4: fix kernel BUG in ext4_write_inline_data_end", " - selftests/bpf: Fix bpf_iter/task_vma test", " - cxl/test: Fix integer overflow in mock LSA bounds checks", " - cxl/test: Zero out LSA backing memory to avoid leaking to user", " - of: cpu: add check in __of_find_n_match_cpu_property()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " - RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " - ASoC: fsl: fsl_audmix: Validate written enum values", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " - net/sched: cls_flow: Dont expose folded kernel pointers", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " - bridge: cfm: reject invalid CCM interval at configuration time", " - sctp: validate embedded address parameter length", " - net/sched: sch_hfsc: Don't make class passive twice", " - tipc: require net admin for TIPCv2 netlink mutators", " - tipc: prevent snt_unacked underflow on CONN_ACK", " - tipc: reject inverted service ranges from peer bindings", " - cxl/test: Add check after kzalloc() memory in alloc_mock_res()", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " - crypto: rng - Free default RNG on module exit", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - power: supply: core: fix supplied_from allocations", " - handshake: Require admin permission for DONE command", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - net: wwan: t7xx: check skb_clone in control TX", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - netfilter: nf_conncount: callers must hold rcu read lock", " - ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait()", " - cifs: remove all cifs files before kill super", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - tipc: fix UAF in tipc_l2_send_msg()", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - ionic: Fix check in ionic_get_link_ext_stats", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - coresight: cti: Fix DT filter signals silently ignored", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - PCI/ASPM: Don't reconfigure ASPM entering low-power state", " - PCI: Introduce named defines for PCI ROM", " - PCI: Check ROM header and data structure addr before accessing", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - mailbox: mtk-adsp: fix UAF during device teardown", " - staging: most: video: avoid double free on video register failure", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " - iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " - iio: tcs3472: power down chip on probe failure", " - clk: at91: keep securam node alive while mapping it", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - fs/ntfs3: add bounds check to run_get_highest_vcn()", " - fs/ntfs3: fix mount failure on 64K page-size kernels", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - pNFS/filelayout: fix cheking if a layout is striped", " - xprtrdma: Remove temp allocation of rpcrdma_rep objects", " - xprtrdma: Avoid 250 ms delay on backlog wakeup", " - xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot", " - xprtrdma: Post receive buffers after RPC completion", " - xprtrdma: Use sendctx DMA state for Send signaling", " - xprtrdma: Decouple req recycling from RPC completion", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - nfs: keep PG_UPTODATE clear after read errors in page groups", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Fix bcall rep leak and unbounded peek", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - apparmor: fix rawdata_f_data implicit flex array", " - apparmor: fix potential UAF in aa_replace_profiles", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - sparc: led: avoid trimming a newline from empty writes", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - spi: dw: fix wrong BAUDR setting after resume", " - xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO", " path", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " - PCI: iproc: Restore .map_irq() for the platform bus driver", " - spi: rpc-if: Use correct device for hardware reinitialization on resume", " - virtio-net: fix len check in receive_big()", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - flow_dissector: check device type before reading ETH_ADDRS", " - ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: Fix data race between add and dump in all hash types", " - netfilter: ipset: annotate \"pos\" for concurrent readers/writers", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash", " types", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - irqchip/crossbar: Fix parent domain resource leak", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - net: marvell: prestera: initialize err in prestera_port_sfp_bind", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " - net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths", " - octeontx2-af: mcs: Fix unsupported secy stats read", " - octeontx2-pf: Clear stats of all resources when freeing resources", " - octeontx2-pf: mcs: Fix mcs resources free on PF shutdown", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: Fix stack slot index in nospec checks", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()", " - ice: fix AQ error code comparison in ice_set_pauseparam()", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - ipv4: fib: Don't ignore error route in local/main tables.", " - bpf, lsm: Add disabled BPF LSM hook list", " - bpf: Disable xfrm_decode_session hook attachment", " - netfilter: nf_nat: avoid invalid nat_net pointer use on failed", " nf_nat_init()", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - netfilter: nft_compat: ebtables emulation must reject non-bridge targets", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - NTB: epf: Report 0-based doorbell vector via ntb_db_event()", " - NTB: epf: Fix doorbell bitmask and IRQ vector handling", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - net, bpf: check master for NULL in xdp_master_redirect()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - net: mvneta: re-enable percpu interrupt on resume", " - net: sungem: fix probe error cleanup", " - net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - net: enetc: check the number of BDs needed for xdp_frame", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - apparmor: check label build before no_new_privs test", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - net/sched: sch_teql: Introduce slaves_lock to avoid race condition and", " UAF", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - cxgb4: Fix decode strings dump for T6 adapters", " - virtio_net: disable cb when NAPI is busy-polled", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - ksmbd: reject undersized DACLs before parsing ACEs", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - pinctrl: meson: restore non-sleeping GPIO access", " - net/sched: hhf: clear heavy-hitter state on reset", " - fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid", " - afs: Fix error code in afs_extract_vl_addrs()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix vllist leak", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " - afs: Fix unchecked-length string display in debug statement", " - minix: avoid overflow in bitmap block count calculation", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: convert READ_ONCE(*ptep) to ptep_get(ptep)", " - arm64/mm: convert set_pte_at() to set_ptes(..., 1)", " - arm64/mm: convert ptep_clear() to ptep_get_and_clear()", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - selftests/hid: convert the hid_bpf selftests with struct_ops", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - gue: validate REMCSUM private option length", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " - amt: fix size calculation in amt_get_size()", " - Bluetooth: 6lowpan: hold L2CAP conn across debugfs control", " - Bluetooth: MGMT: Fix adv monitor add failure cleanup", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - ring-buffer: Fix event length with forced 8-byte alignment", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: move functions to avoid forward definitions", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " - ipv6: mcast: Replace locking comments with lockdep annotations.", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " - s390/zcrypt: Remove the empty file", " - cifs: validate DFS referral string offsets", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " - dm era: fix NULL pointer dereference in metadata_open()", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " - selftests/net: fix EVP_MD_CTX leak in tcp_mmap", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - octeontx2-af: fix VF bringup affecting PF promiscuous state", " - smb: client: fix overflow in passthrough ioctl bounds check", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " - ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put", " - ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc", " - ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get", " - ASoC: SOF: topology: validate vendor array size before parsing", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " - net: atm: reject out-of-range traffic classes in QoS validation", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " - fbdev: vesafb: fix memory leak in vesafb_probe()", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " - ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get", " - ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Release reserved memory on cleanup", " - ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_cluster: reject template conntracks in hash match", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - netfilter: nf_nat_sip: reload possible stale data pointer", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " - netfilter: ecache: fix inverted time_after() check", " - netfilter: xt_nat: reject unsupported target families", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - selinux: check connect-related permissions on TCP Fast Open", " - leds: uleds: Fix potential buffer overread", " - mfd: sm501: Fix reference leak on failed device registration", " - tools/power/x86/intel-speed-select: Harden daemon pidfile open", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " - x86/boot: Reject too long acpi_rsdp= values", " - perf/x86/amd/lbr: Fix kernel address leakage", " - s390/perf_cpum_cf: Add missing array_index_nospec() to", " __hw_perf_event_init()", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: bla: reacquire gw address after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: tt: avoid request storms during pending request", " - batman-adv: fix VLAN priority offset", " - batman-adv: frag: free unfragmentable packet", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: tt: prevent TVLV OOB check overflow", " - cifs: invalidate cfid on unlink/rename/rmdir", " - mfd: tps6586x: Fix OF node refcount", " - HID: playstation: validate num_touch_reports in DualShock 4 reports", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " - nvdimm/btt: Free arenas on btt_init() error paths", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - mm/damon/core: make charge_addr_from aware of end-address exclusivity", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " - fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " - riscv: cacheinfo: Fix node reference leak in populate_cache_leaves", " - mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs()", " - mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error", " - proc: only bump parent nlink when registering directories", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - mtd: rawnand: pl353: fix probe resource allocation", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " - mtd: rawnand: fix condition in 'nand_select_target()'", " - ocfs2: avoid moving extents to occupied clusters", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " - ocfs2: add journal NULL check in ocfs2_checkpoint_inode()", " - ocfs2: reject dinodes with non-canonical i_mode type", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " - fpga: dfl: add bounds check in dfh_get_param_size()", " - bus: mhi: ep: Protect mhi_ep_handle_syserr() in the error path", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - fpga: microchip-spi: fix zero header_size OOB read in", " mpf_ops_parse_header()", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86/amd/pmc: Check for intermediate wakeup in function", " - platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops", " - platform/x86/amd/pmc: Add delay_suspend module parameter", " - smb: client: use kvzalloc() for megabyte buffer in simple fallocate", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - ice: fix ice_init_link() error return preventing probe", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - tpm: Make the TPM character devices non-seekable", " - time: Fix off-by-one in compat settimeofday() usec validation", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " - sctp: validate STALE_COOKIE cause length before reading staleness", " - nvmet-rdma: handle inline data with a nonzero offset", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " - can: bcm: add missing rcu list annotations and operations", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - net: sparx5: unregister blocking notifier on init failure", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " - dm era: fix out-of-bounds memory access for non-zero start sector", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-ioctl: fix a possible overflow in list_version_get_info", " - dm-log: fix a bitset_size overflow on 32bit machines", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm_early_create: fix freeing used table on dm_resume failure", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - scsi: sg: Report request-table problems when any status is set", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - validate control endpoint type", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - Input: ims-pcu - fix race condition in reset_device sysfs callback", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " - net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio-f7188x: Add support for NCT6126D version B", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: wwan: t7xx: destroy DMA pool on CLDMA late init failure", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - net: ena: clean up XDP TX queues when regular TX setup fails", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " - ieee802154: admin-gate legacy LLSEC dump operations", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " - batman-adv: ensure minimal ethernet header on TX", " - batman-adv: clean untagged VLAN on netdev registration failure", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - espintcp: use sk_msg_free_partial to fix partial send", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: mpfs: fix counter upload completion condition", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - net: liquidio: fix BAR resource leak on PF number failure", " - hwmon: (occ) unregister sysfs devices outside occ lock", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - net: lan743x: Initialize eth_syslock spinlock before use", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - net: wwan: iosm: bound device offsets in the MUX downlink decoder", " - hwmon: (asus_atk0110) Check package count before accessing element", " - riscv: probes: save original sp in rethook trampoline", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - drbd: reject data replies with an out-of-range payload size", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " - pmdomain: imx: Fix i.MX8MP power notifier", " - pmdomain: imx: Fix i.MX8MP VC8000E power up sequence", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - Bluetooth: btrtl: validate firmware patch bounds", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - memstick: ms_block: reject a card that reports too many blocks", " - ipvs: fix more places with wrong ipv6 transport offsets", " - ipvs: reload ip header after head reallocation", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: mac80211: free ack status frame on TX header build failure", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " - mtd: onenand: samsung: report DMA completion timeouts", " - mtd: mchp23k256: use SPI match data for chip caps", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " - perf/x86/amd/brs: Fix kernel address leakage", " - ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup", " - ACPI: bus: Introduce devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Use devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Fix possible deadlock and missing notifications", " - iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - iio: invensense: remove redundant initialization of variable period", " - iio: invensense: fix timestamp glitches when switching frequency", " - iio: imu: inv_icm42600: stabilized timestamp in interrupt", " - iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading", " - iio: pressure: mpl115: fix runtime PM leak on read error", " - bitops: make BYTES_TO_BITS() treewide-available", " - iio: common: st_sensors: honour channel endianness in read_axis_data", " - ALSA: aoa: check snd_ctl_new1() return value", " - PCI: altera: Fix resource leaks on probe failure", " - vfio/mlx5: Fix racy bitfields and tighten struct layout", " - PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling", " - PCI: controller: Use dev_fwnode() instead of of_fwnode_handle()", " - PCI: mediatek: Convert bool to single quirks entry and bitmap", " - PCI: mediatek: Use generic MACRO for TPVPERL delay", " - PCI: mediatek: Fix IRQ domain leak when port fails to enable", " - PCI: Prevent resource tree corruption when BAR resize fails", " - PCI: Free saved list without holding pci_bus_sem", " - PCI: Fix restoring BARs on BAR resize rollback path", " - PCI: Add kerneldoc for pci_resize_resource()", " - PCI: Move Resizable BAR code to rebar.c", " - PCI: Skip Resizable BAR restore on read error", " - staging: rtl8723bs: core: move constants to right side in comparison", " - staging: rtl8723bs: fix spaces around binary operators", " - staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),", " rtw_get_wapi_ie(), and rtw_get_wps_attr()", " - crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()", " - Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref", " - mm/shrinker: do not hold RCU lock in shrinker_debugfs_count_show()", " - coresight: etb10: restore atomic_t for shared reading state", " - gpio: sch: use raw_spinlock_t in the irq startup path", " - media: nxp: imx8-isi: Convert to platform remove callback returning void", " - media: nxp: imx8-isi: use devm_pm_runtime_enable() to simplify code", " - media: nxp: imx8-isi: Fix use-after-free on remove", " - netfilter: ebtables: Use vmalloc_array() to improve code", " - netfilter: ebtables: zero chainstack array", " - Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - smb: client: Improve unlocking of a mutex in cifs_get_swn_reg()", " - smb: client: resolve SWN tcon from live registrations", " - ksmbd: use opener credentials for FSCTL mutations", " - ksmbd: centralize ksmbd_conn final release to plug transport leak", " - ksmbd: track the connection owning a byte-range lock", " - proc: rename proc_setattr to proc_nochmod_setattr", " - proc: protect ptrace_may_access() with exec_update_lock (FD links)", " - writeback: fix race between cgroup_writeback_umount() and", " inode_switch_wbs()", " - perf/x86/intel/uncore: Defer ADL global PMON enable to enable_box()", " - HID: add haptics page defines", " - HID: multitouch: fix out-of-bounds bit access on mt_io_flags", " - mm/slab: do not limit zeroing to orig_size when only red zoning is", " enabled", " - seqlock: Introduce scoped_seqlock_read()", " - seqlock: Change do_task_stat() to use scoped_seqlock_read()", " - proc: protect ptrace_may_access() with exec_update_lock (part 1)", " - treewide: Switch/rename to timer_delete[_sync]()", " - HID: appleir: fix UAF on pending key_up_timer in remove()", " - serial: 8250_mid: Disable DMA for selected platforms", " - hfs/hfsplus: prevent getting negative values of offset/length", " - hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length", " - bpf: Consistently use bpf_rcu_lock_held() everywhere", " - bpf: Allow LPM map access from sleepable BPF programs", " - usb: iowarrior: remove inherent race with minor number", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - usb: typec: tcpm: Fix VDM type for Enter Mode commands", " - crypto: atmel - Drop explicit initialization of struct", " i2c_device_id::driver_data to 0", " - crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A", " - usb: gadget: f_fs: initialize reset_work at allocation time", " - nvmet: return DHCHAP status codes from nvmet_setup_auth()", " - nvmet-auth: validate reply message payload bounds against transfer", " length", " - usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile", " - btrfs: check and set EXTENT_DELALLOC_NEW before clearing EXTENT_DELALLOC", " - crypto: qat - fix restarting state leak on allocation failure", " - audit: add audit_log_nf_skb helper function", " - audit: fix potential integer overflow in audit_log_n_hex()", " - regulator: scmi: Simplify with scoped for each OF child loop", " - regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()", " - mm: do file ownership checks with the proper mount idmap", " - exfat: move free cluster out of exfat_init_ext_entry()", " - exfat: remove unnecessary read entry in __exfat_rename()", " - exfat: rename argument name for exfat_move_file and exfat_rename_file", " - exfat: add exfat_get_dentry_set_by_ei() helper", " - exfat: move exfat_chain_set() out of __exfat_resolve_path()", " - exfat: preserve benign secondary entries during rename and move", " - btrfs: fix false IO failure after falling back to buffered write", " - btrfs: fix incorrect buffered IO fallback for append direct writes", " - Bluetooth: hci_core: Enable buffer flow control for SCO/eSCO", " - Bluetooth: separate CIS_LINK and BIS_LINK link types", " - Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - seqlock: fix scoped_seqlock_read kernel-doc", " - Bluetooth: hci_core: Remove check of BDADDR_ANY in", " hci_conn_hash_lookup_big_state", " - Bluetooth: hci_sync: Fix attempting to send HCI_Disconnect to BIS handle", " - Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote", " netdev", " - selftests/hid: ensure CKI can compile our new tests on old kernels", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error harder", " - Bluetooth: btmtk: remove #ifdef around declarations", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - jiffies: Define secs_to_jiffies()", " - jiffies: Cast to unsigned long in secs_to_jiffies() conversion", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - tools/testing: add linux/args.h header and fix radix, VMA tests", " - selftests/bpf: Add simple strscpy() implementation", " - bcachefs: avoid truncating fiemap extent length", " - gpio: rockchip: change the GPIO version judgment logic", " - gpio: rockchip: teardown bugs and resource leaks", " - gpio: rockchip: fix generic IRQ chip leak on remove", " - NFSv4/flexfiles: Remove cred local variable dependency", " - iio: resolver: ad2s1210: notify trigger and clear state on fault read", " error", " - iio: temperature: Build mlx90635 with CONFIG_MLX90635", " - vfio: Remove device debugfs before releasing devres", " - PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000", " series", " - netpoll: fix a use-after-free on shutdown path", " - mm: shrinker: fix shrinker_info teardown race with expansion", " - NFSv4/flexfiles: Add data structure support for striped layouts", " - mm/khugepaged: write all dirty file folios when collapsing", " - platform/x86: intel-hid: Protect ACPI notify handler against recursion", " - Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled", " - Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()", " - fs/ntfs3: rename ni_readpage_cmpr into ni_read_folio_cmpr", " - ksmbd: use __GFP_RETRY_MAYFAIL", " - ksmbd: use opener credentials for ADS I/O", " - cpufreq: Make cpufreq_driver->exit() return void", " - cpufreq: qcom-cpufreq-hw: Fix possible double free", " - nvme: target: rdma: fix ndev refcount leak on queue connect", " - nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page", " - crypto: qat - keep VFs enabled during reset", " - crypto: qat - notify fatal error before AER reset preparation", " - crypto: qat - protect service table iterations with service_lock", " - selftests/mm: pagemap_ioctl: use the correct page size for", " transact_test()", " - iommufd: Set upper bounds on cache invalidation entry_num and entry_len", " - iommu/amd: Don't split flush for amd_iommu_domain_flush_all()", " - dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning", " - i2c: core: fix adapter probe deferral loop", " - xfs: fix null pointer dereference in tracepoint", " - xfs: don't wrap around quota ids in dqiterate", " - xfs: clamp timestamp nanoseconds correctly", " - xfs: don't zap bmbt forks if they are MAXLEVELS tall", " - iommu/vt-d: Clear Present bit before tearing down context entry", " - iommu: Pass old domain to set_dev_pasid op", " - iommu/vt-d: Cleanup intel_context_flush_present()", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " - vsock/virtio: bind uarg before filling zerocopy skb", " - iommu/amd: Use maximum Event log buffer size when SNP is enabled on", " Family 0x19", " - iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family", " 0x19", " - net: dropreason: Gather SOCKET_ drop reasons.", " - af_unix: Set drop reason in unix_release_sock().", " - af_unix: Set drop reason in manage_oob().", " - af_unix: Set drop reason in unix_stream_read_skb().", " - af_unix/scm: fix whitespace errors", " - af_unix: Don't hold unix_state_lock() in __unix_dgram_recvmsg().", " - af_unix: Don't check SOCK_DEAD in unix_stream_read_skb().", " - af_unix: Don't use skb_recv_datagram() in unix_stream_read_skb().", " - af_unix: Drop all SCM attributes for SOCKMAP.", " - time/jiffies: Change register_refined_jiffies() to void __init", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - media: uvcvideo: Do not add clock samples with small sof delta", " - serial: max310x: replace bare use of 'unsigned' with 'unsigned int'", " (checkpatch)", " - serial: max310x: implement gpio_chip::get_direction()", " - drm/gpuvm: Do not prepare NULL objects", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - soc: xilinx: Shutdown and free rx mailbox channel", " - crypto: qat - fix heartbeat error injection", " - memory: tegra: Wire up system sleep PM ops", " - drm/gpuvm: take refcount on DRM device", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - RDMA/hns: Initialize seqfile before creating file", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - RDMA/hns: Fix log flood after cmd_mbox failure", " - net: introduce page_frag_cache_drain()", " - nvmet-tcp: fix page fragment cache leak in error path", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - driver core: Use system_percpu_wq instead of system_wq", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - x86/cpu/amd: Provide a separate accessor for Node ID", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - netfilter: nfnetlink_cthelper: use {READ,WRITE}_ONCE for accessing", " helper flags", " - netfilter: synproxy: drop packets if timestamp adjustment fails", " - netfilter: synproxy: adjust duplicate timestamp options", " - netfilter: synproxy: fix unaligned memory access in timestamp adjustment", " - RDMA/siw: Fix endpoint/socket association handling", " - riscv: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - virtio_console: read size from config space during device init", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - net: dsa: qca8k: fix led devicename when using external mdio bus", " - ALSA: seq: Drop superfluous filter argument of get_event_dest_client()", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - dpll: add reference-sync netlink attribute", " - dpll: move xa_erase() call in to match dpll_pin_alloc() error path order", " - dpll: add reference sync get/set", " - dpll: Allow associating dpll pin with a firmware node", " - dpll: Add notifier chain for dpll events", " - dpll: Support dynamic pin index allocation", " - dpll: Enhance and consolidate reference counting logic", " - dpll: fix stale iteration in dpll_pin_on_pin_unregister()", " - dpll: send delete notification before unregister in on-pin rollback", " - dpll: emit per-dpll delete notifications in dpll_pin_on_pin_unregister()", " - dpll: guard sync-pair removal on full pin unregister", " - dpll: balance create/delete notifications in __dpll_pin_(un)register", " - landlock: Fix unmarked concurrent access to socket family", " - selftests/bpf: Fix typo in verify_umulti_link_info", " - udf: fix nls leak on udf_fill_super() failure", " - mfd: rsmu: Fix page register setup", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: split ep_insert() into alloc + register stages", " - eventpoll: extract ep_deliver_event() from ep_send_events()", " - eventpoll: wrap EP_UNACTIVE_PTR in typed sentinel helpers", " - eventpoll: rename epi->next and txlist for clarity", " - eventpoll: Fix epoll_wait() report false negative", " - gpiolib: acpi: Only trigger ActiveBoth interrupts on boot", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - PCI: meson: Add missing remove callback", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - workqueue: Add new WQ_PERCPU flag", " - i3c: master: add WQ_PERCPU to alloc_workqueue users", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - xfrm: Fix xfrm state cache insertion race", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - netfilter: ipset: make sure gc is properly stopped", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: hugetlb_reparenting_test: do not unmount", " - selftests/mm: save and restore nr_hugepages value", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - ipv6: annotate data-races around cnf.forwarding", " - ipv6/addrconf: annotate data-races around devconf fields (II)", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_info", " - ice: dpll: fix memory leak in ice_dpll_init_info error paths", " - net: bnxt: use ethtool string helpers", " - eth: bnxt: gather and report HW-GRO stats", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - ipv6: Add __in6_dev_get_rtnl_net().", " - octeontx2-af: Validate NIX maximum LFs correctly", " - udp_tunnel: remove rtnl_lock dependency", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - net: hisilicon: hns3: use ethtool string helpers", " - net: hns3: use string choices helper", " - net: hns3: use hns3_get_ae_dev() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: use hns3_get_ops() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: clear hns alarm: comparison of integer expressions of", " different signedness", " - net: hns3: unify copper port ksettings configuration path", " - net: hns3: refactor MAC autoneg and speed configuration", " - net: hns3: fix permanent link down deadlock after reset", " - net: hns3: differentiate autoneg default values between copper and fiber", " - rtnetlink: Add per-netns RTNL.", " - [Config] Set CONFIG_DEBUG_NET_SMALL_RTNL=n", " - rtnetlink: Add assertion helpers for per-netns RTNL.", " - rtnetlink: Define rtnl_net_trylock().", " - ipv6: Convert net.ipv6.conf.${DEV}.XXX sysctl to per-netns RTNL.", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Make /afs/. as well as /afs/ mountpoints", " - afs: Add rootcell checks", " - afs: Make /afs/@cell and /afs/.@cell symlinks", " - afs: Fix afs_atcell_get_link() to handle RCU pathwalk", " - afs: Remove the \"autocell\" mount option", " - afs: Change dynroot to create contents on demand", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - ovl: fix comment about locking order", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - afs: Convert comma to semicolon", " - afs: Fix double netfs initialisation in afs_root_iget()", " - drm/xe: Add warn when level can not be zero.", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - HID: bpf: Fix hid_bpf_get_data() range check", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - genirq/generic_chip: Introduce irq_domain_{alloc,remove}_generic_chips()", " - gpio: mvebu: free generic chips on unbind", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " - drm/xe: remove duplicate include", " - LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()", " - LoongArch: KVM: Check the return values for put_user()", " - LoongArch: KVM: Fix FPU register width with user access API", " - LoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr()", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - fbdev: efifb: fix memory leak in efifb_probe()", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - batman-adv: mcast: avoid OOB read of num_dests header", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()", " - fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry()", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - taskstats: retain dead thread stats in TGID queries", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - NFS: Charge unstable writes by request size, not folio size", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: make error counter atomic", " - accel/ivpu: Reject firmware log with size smaller than header", " - firmware_loader: introduce __free() cleanup hanler", " - Input: ims-pcu - fix firmware leak in async update", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - gpio: tegra: do not call pinctrl for GPIO direction", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - s390: Revert support for DCACHE_WORD_ACCESS", " - [Config] Set CONFIG_DCACHE_WORD_ACCESS=- for s390x", " - selftests: net: make busywait timeout clock portable", " - ata: libata: Use QUIRK instead of HORKAGE", " - ata: libata-core: Skip HPA resize for locked drives", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - ALSA: hda/cs35l41: Fix firmware load work teardown", " - io_uring/rw: ensure reissue path is correctly handled for IOPOLL", " - io_uring/rw: preserve partial result for iopoll", " - Bluetooth: L2CAP: Fix not tracking outstanding TX ident", " - mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless", " host", " - ksmbd_vfs_rename(): vfs_path_parent_lookup() accepts ERR_PTR() as name", " - vfs: make LAST_XXX private to fs/namei.c", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " - HID: pidff: Fix missing blank lines after declarations", " - HID: pidff: Add missing spaces", " - HID: pidff: Rework pidff_upload_effect", " - HID: pidff: Use correct effect type in effect update", " - bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()", " - USB: iowarrior: fix use-after-free on disconnect race", " - crypto: atmel-sha204a - fail on hwrng registration error in probe path", " - btrfs: concentrate the error handling of submit_one_sector()", " - btrfs: remove folio parameter from ordered io related functions", " - btrfs: remove the COW fixup mechanism", " - slab: Introduce kmalloc_obj() and family", " - slab: Introduce kmalloc_flex() and family", " - add default_gfp() helper macro and use it in the new *alloc_obj()", " helpers", " - default_gfp(): avoid using the \"newfangled\" __VA_OPT__ trick", " - slab: recognize @GFP parameter as optional in kernel-doc", " - fscrypt: Fix key setup in edge case with multiple data unit sizes", " - fscrypt: Replace mk_users keyring with simple list", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is", " uninitialized", " - rtnetlink: Make per-netns RTNL dereference helpers to macro.", " - afs: Fix afs_atcell_get_link() to check if ws_cell is unset first", " - afs: Fix afs_dynroot_readdir() to not use the RCU read lock", " - udp_tunnel: fix deadlock in udp_tunnel_nic_set_port_priv()", " - i40e: drop udp_tunnel_get_rx_info() call from i40e_open()", " - ice: drop udp_tunnel_get_rx_info() call from ndo_open()", " - Bluetooth: L2CAP: Fix regressions caused by reusing ident", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " - perf: Reject exited events as group leaders", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - proc: Fix broken error paths for namespace links", " - Upstream stable to v6.6.145, v6.12.96, v6.12.97", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2026-53365", " - vsock/virtio: fix zerocopy completion for multi-skb sends", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two", " - x86/mm: Fix check/use ordering in switch_mm_irqs_off()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192)", " - debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING", " - debugobjects: Use LD_WAIT_CONFIG instead of LD_WAIT_SLEEP", " - debugobjects: Dont call fill_pool() in early boot hardirq context", " - ARM: group is_permission_fault() with is_translation_fault()", " - ARM: allow __do_kernel_fault() to report execution of memory faults", " - ARM: fix branch predictor hardening", " - RDMA/bnxt_re: zero shared page before exposing to userspace", " - selftests/bpf: Add test to ensure kprobe_multi is not sleepable", " - bpf: Remove mark_precise_scalar_ids()", " - selftests/bpf: Tests for per-insn sync_linked_regs() precision tracking", " - selftests/bpf: Update comments find_equal_scalars->sync_linked_regs", " - hv: utils: handle and propagate errors in kvp_register", " - Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs", " - phonet: Pass ifindex to fill_addr().", " - phonet: Pass net and ifindex to phonet_address_notify().", " - scripts/sorttable: Remove unused macro defines", " - scripts/sorttable: Remove unused write functions", " - scripts/sorttable: Remove unneeded Elf_Rel", " - scripts/sorttable: Have the ORC code use the _r() functions to read", " - scripts/sorttable: Make compare_extable() into two functions", " - scripts/sorttable: Convert Elf_Ehdr to union", " - scripts/sorttable: Replace Elf_Shdr Macro with a union", " - scripts/sorttable: Convert Elf_Sym MACRO over to a union", " - scripts/sorttable: Add helper functions for Elf_Ehdr", " - scripts/sorttable: Add helper functions for Elf_Shdr", " - scripts/sorttable: Add helper functions for Elf_Sym", " - scripts/sorttable: Use uint64_t for mcount sorting", " - scripts/sorttable: Move code from sorttable.h into sorttable.c", " - scripts/sorttable: Get start/stop_mcount_loc from ELF file directly", " - scripts/sorttable: Use a structure of function pointers for elf helpers", " - arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64", " - [Config] Set configs to sort mcount_loc at boot for arm64", " - scripts/sorttable: Have mcount rela sort use direct values", " - scripts/sorttable: Always use an array for the mcount_loc sorting", " - scripts/sorttable: Zero out weak functions in mcount_loc table", " - ftrace: Update the mcount_loc check of skipped entries", " - ftrace: Have ftrace pages output reflect freed pages", " - ftrace: Do not over-allocate ftrace memory", " - ftrace: Test mcount_loc addr before calling ftrace_call_addr()", " - ftrace: Check against is_kernel_text() instead of kaslr_offset()", " - scripts/sorttable: Use normal sort if theres no relocs in the mcount", " section", " - scripts/sorttable: Allow matches to functions before function entry", " - scripts/sorttable: Fix endianness handling in build-time mcount sort", " - file: add fput() cleanup helper", " - eventpoll: use hlist_is_singular_node() in __ep_remove()", " - Revert \"ptp: add testptp mask test\"", " - Bluetooth: btmtk: validate WMT event SKB length before struct access", " - Bluetooth: btmtk: accept too short WMT FUNC_CTRL events", " - batman-adv: tp_meter: keep unacked list in ascending ordered", " - batman-adv: tp_meter: initialize dup_acks explicitly", " - batman-adv: tp_meter: initialize dec_cwnd explicitly", " - batman-adv: tp_meter: avoid window underflow", " - batman-adv: tp_meter: fix fast recovery precondition", " - batman-adv: tp_meter: handle seqno wrap-around for fast recovery", " detection", " - batman-adv: tp_meter: add only finished tp_vars to lists", " - batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE", " - batman-adv: prevent ELP transmission interval underflow", " - batman-adv: tp_meter: initialize last_recv_time during init", " - batman-adv: ensure bcast is writable before modifying TTL", " - batman-adv: fix (m|b)cast csum after decrementing TTL", " - batman-adv: frag: ensure fragment is writable before modifying TTL", " - batman-adv: frag: avoid underflow of TTL", " - batman-adv: tp_meter: annotate last_recv_time access with", " READ/WRITE_ONCE", " - batman-adv: tp_meter: prevent parallel modifications of last_recv", " - batman-adv: tp_meter: handle overlapping packets", " - batman-adv: tt: don't merge change entries with different VIDs", " - batman-adv: tt: track roam count per VID", " - batman-adv: dat: prevent false sharing between VLANs", " - batman-adv: tvlv: enforce 2-byte alignment", " - batman-adv: tvlv: avoid race of cifsnotfound handler state", " - inet: add indirect call wrapper for getfrag() calls", " - err.h: use __always_inline on all error pointer helpers", " - wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S", " - wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor", " - wifi: rtw88: increase TX report timeout to fix race condition", " - wifi: iwlwifi: mvm: fix race condition in PTP removal", " - f2fs: fix to round down start offset of fallocate for pin file", " - f2fs: keep atomic write retry from zeroing original data", " - MIPS: DEC: Prevent initial console buffer from landing in XKPHYS", " - fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode", " - nfsd: check get_user() return when reading princhashlen", " - NFS: Prevent resource leak in nfs_alloc_server()", " - serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero", " - wifi: mt76: mt7921: avoid undesired changes of the preset regulatory", " domain", " - ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()", " - xfs: fix error returns in CoW fork repair", " - locking/mutex: Remove wakeups from under mutex::wait_lock", " - net: ipv6: Make udp_tunnel6_xmit_skb() void", " - Revert \"PCI: qcom: Advertise Hotplug Slot Capability with no Command", " Completion support\"", " - KVM: SEV: Ignore MMIO requests of length '0'", " - mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program", " - mtd: spi-nor: macronix: add support for mx66{l2, u1}g45g", " - LoongArch: Report dying CPU to RCU in stop_this_cpu()", " - MIPS: smp: report dying CPU to RCU in stop_this_cpu()", " - locking: rtmutex: Fix wake_q logic in task_blocks_on_rt_mutex", " - bonding: annotate data-races arcound churn variables", " - Upstream stable to v6.6.144, v6.12.95", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53389", " - net/tcp-ao: fix use-after-free of key in del_async path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53393", " - nfsd: reset write verifier on deferred writeback errors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53400", " - i2c: core: fix adapter registration race", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63806", " - KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with", " get_unaligned()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63940", " - KVM: SEV: Ignore Port I/O requests of length '0'", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53387", " - iio: light: veml6075: add bounds check to veml6075_it_ms index", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53070", " - sctp: disable BH before calling udp_tunnel_xmit_skb()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43216", " - net: Drop the lock in skb_may_tx_timestamp()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64244", " - drivers/base/memory: set mem->altmap after successful device", " registration", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53384", " - serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53390", " - ksmbd: fix out-of-bounds read in smb_check_perm_dacl()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53391", " - NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53397", " - nfsd: fix posix_acl leak on SETACL decode failure", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64245", " - fbdev: modedb: fix a possible UAF in fb_find_mode()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53403", " - fbdev: Fix fb_new_modelist to prevent null-ptr-deref in", " fb_videomode_to_var", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64246", " - power: reset: linkstation-poweroff: fix use-after-free in the", " linkstation_poweroff_init()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63794", " - KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64247", " - KVM: x86: hyper-v: Bound the bank index when querying sparse banks", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63795", " - 9p: avoid putting oldfid in p9_client_walk() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63796", " - ocfs2: reject oversized group bitmap descriptors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63797", " - rpmsg: char: Fix use-after-free on probe error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64249", " - fpga: region: fix use-after-free in child_regions_with_firmware()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63798", " - irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup", " on remove", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63801", " - tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63802", " - blk-cgroup: fix UAF in __blkcg_rstat_flush()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63803", " - hdlc_ppp: sync per-proto timers before freeing hdlc state", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63804", " - gfs2: fix use-after-free in gfs2_qd_dealloc", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63809", " - bpf: use kvfree() for replaced sysctl write buffer", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63812", " - f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63814", " - f2fs: validate ACL entry sizes in f2fs_acl_from_disk()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63817", " - f2fs: validate compress cache inode only when enabled", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63821", " - wifi: rtw88: usb: fix memory leaks on USB write failures", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63822", " - wifi: ath11k: fix warning when unbinding", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63823", " - keys: Pin request_key_auth payload in instantiate paths", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63824", " - KEYS: fix overflow in keyctl_pkey_params_get_2()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63826", " - fbdev: fix use-after-free in store_modes()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64254", " - NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG", " share BAR", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63827", " - apparmor: fix use-after-free in rawdata dedup loop", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63828", " - apparmor: mediate the implicit connect of TCP fast open sendmsg", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63830", " - net: skmsg: preserve sg.copy across SG transforms", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63831", " - mac802154: llsec: add skb_cow_data() before in-place crypto", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53361", " - af_unix: Set gc_in_progress to true in unix_gc().", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63833", " - ntfs3: reject direct userspace writes to reserved $LX* xattrs", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53366", " - ipv4: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53362", " - ipv6: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63834", " - batman-adv: tp_meter: restrict number of unacked list entries", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63835", " - batman-adv: v: prevent OGM aggregation on disabled hardif", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63836", " - batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63807", " - KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping", " level", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53381", " - virtiofs: fix UAF on submount umount", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53382", " - media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53383", " - ksmbd: reject non-VALID session in compound request branch", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53385", " - vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent", " vcs_write", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53388", " - fuse: re-lock request before replacing page cache folio", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53157", " - net: phonet: free phonet_device after RCU grace period", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53163", " - locking/rtmutex: Skip remove_waiter() when waiter is not enqueued", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2025-23131", " - dlm: prevent NPD when writing a positive value to event_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-46252", " - regulator: core: fix locking in regulator_resolve_supply() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52928", " - af_unix: Reject SIOCATMARK on non-stream sockets", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43010", " - bpf: Reject sleepable kprobe_multi programs at attach time", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53325", " - agp/amd64: Fix broken error propagation in agp_amd64_probe()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64188", " - net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64191", " - i2c: stub: Reject I2C block transfers with invalid length", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53327", " - debugobjects: Do not fill_pool() if pi_blocked_on", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52909", " - ip6_vti: set netns_immutable on the fallback device.", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53167", " - fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios", "" ], "package": "linux", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 11:03:24 +0200" }, { "cves": [ { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-146.146 -proposed tracker (LP: #2166353)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", "", " * Bluetooth fails to initialize due to a kernel NULL pointer error", " (LP: #2165873)", " - Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c", "", " * Dell Precision fails to shutdown when HDMI display is connected (22.04", " HWE) (LP: #2164507)", " - drm/i915/vbt: Add fields dedicated_external and dyn_port_over_tc", " - drm/i915/display: Handle dedicated external ports in", " intel_encoder_is_tc()", "", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", "", " * [SRU] HPE: Fix for UBSAN array-index-out-of-bounds (LP: #2161004)", " - x86/platform/uv: Fix UBSAN array-index-out-of-bounds", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough", " (LP: #2089306)", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Reboot machine with ext4 configured to data=journal could dump spurious", " call trace (LP: #2164716)", " - ext4: clear stale xarray tags on folios skipped during writeback", "", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", "", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796)", " - netfilter: bitwise: rename some boolean operation functions", " - netfilter: bitwise: add support for doing AND, OR and XOR directly", " - drm/fbdev-helper: Set and clear VGA switcheroo client from fb_info", " - arm64: io: Rename ioremap_prot() to __ioremap_prot()", " - Disable -Wattribute-alias for clang-23 and newer", " - netfilter: xt_NFQUEUE: prefer raw_smp_processor_id", " - drm/imx: Fix three kernel-doc warnings in dcss-scaler.c", " - pcnet32: stop holding device spin lock during napi_complete_done", " - net: Annotate sk->sk_write_space() for UDP SOCKMAP.", " - net: lan743x: permit VLAN-tagged packets up to configured MTU", " - net: fec: fix pinctrl default state restore order on resume", " - Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame()", " extension handling", " - Bluetooth: MGMT: Fix backward compatibility with userspace", " - ptp: vclock: Switch from RCU to SRCU", " - octeontx2-af: npc: Fix CPT channel mask in npc_install_flow", " - vxlan: vnifilter: send notification on VNI add", " - vxlan: vnifilter: fix spurious notification on VNI update", " - ipmi: Fix rcu_read_unlock to srcu_read_unlock in handle_read_event_rsp", " - time: Fix off-by-one in settimeofday() usec validation", " - tools/rv: Fix cleanup after failed trace setup", " - arm64: tlb: Allow XZR argument to TLBI ops", " - iomap: don't revert iov_iter on partially completed buffered writes", " - net/mlx4: avoid GCC 10 __bad_copy_from() false positive", " - r8152: handle the return value of usb_reset_device()", " - rds: mark snapshot pages dirty in rds_info_getsockopt()", " - net: mvpp2: Add metadata support for xdp mode", " - net: mvpp2: build skb from XDP-adjusted data on XDP_PASS", " - clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time", " - tracing/probes: Point the error offset correctly for eprobe argument", " error", " - mmc: litex_mmc: Use DIV_ROUND_UP for more accurate clock calculation", " - USB: serial: option: add usb-id for Dell Wireless DW5826e-m", " - ALSA: timer: Fix UAF at snd_timer_user_params()", " - drm/amd/display: Reject gpio_bitshift >= 32 in", " bios_parser_get_gpio_pin_info()", " - mm/damon/ops-common: call folio_test_lru() after folio_get()", " - ARM: socfpga: Fix OF node refcount leak in SMP setup", " - ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O", " - mptcp: fix retransmission loop when csum is enabled", " - mptcp: sockopt: check timestamping ret value", " - selftests: mptcp: add test for extra_subflows underflow on userspace PM", " - ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write", " - inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush", " - pidfd: refuse access to tasks that have started exiting harder", " - i2c: stm32f7: fix timing computation ignoring i2c-analog-filter", " - i2c: tegra: Fix NOIRQ suspend/resume", " - Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)", " - Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard", " - net/mlx5: Reorder completion before putting command entry in", " cmd_work_handler", " - net: mv643xx: fix OF node refcount", " - octeontx2-af: fix memory leak in rvu_setup_hw_resources()", " - mmc: core: Fix host controller programming for fixed driver type", " - mmc: litex_mmc: Set mandatory idle clocks before CMD0", " - mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC", " - mmc: sdhci: add signal voltage switch in sdhci_resume_host", " - slimbus: qcom-ngd-ctrl: fix OF node refcount", " - drm/amdgpu: restart the CS if some parts of the VM are still invalidated", " - fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling", " - driver core: reject devices with unregistered buses", " - mm/hugetlb: avoid false positive lockdep assertion", " - soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get()", " - ipmi:ssif: Remove unnecessary indention", " - ipmi:ssif: NULL thread on error", " - selftests: mptcp: drop nanoseconds width specifier", " - tty: serial: samsung: use u32 for register interactions", " - RDMA/umem: fix kernel-doc warnings", " - RDMA: Move DMA block iterator logic into dedicated files", " - arm64: cputype: Add NVIDIA Olympus definitions", " - arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU", " - mptcp: add-addr: always drop other suboptions", " - mptcp: fix missing wakeups in edge scenarios", " - Revert \"selftest/ptp: update ptp selftest to exercise the gettimex", " options\"", " - ARM: fix hash_name() fault", " - wifi: remove zero-length arrays", " - soc: qcom: ice: Return -ENODEV if the ICE platform device is not found", " - Bluetooth: ISO: Fix not using bc_sid as advertisement SID", " - octeontx2-pf: Fix NDC sync operation errors", " - octeontx2-af: Fix initialization of mcam's entry2target_pffunc field", " - ima: kexec: skip IMA segment validation after kexec soft reboot", " - ima: kexec: move IMA log copy from kexec load to execute", " - gpio: zynq: fix runtime PM leak on remove", " - writeback: Avoid contention on wb->list_lock when switching inodes", " - writeback: Fix use after free in inode_switch_wbs_work_fn()", " - xfrm: hold device only for the asynchronous decryption", " - KVM: VMX: Update SVI during runtime APICv activation", " - drm/xe: fix refcount leak in xe_range_fence_insert()", " - slimbus: qcom-ngd-ctrl: Fix up platform_driver registration", " - slimbus: qcom-ngd-ctrl: Fix probe error path ordering", " - slimbus: qcom-ngd-ctrl: Initialize controller resources in controller", " - slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership", " - slimbus: qcom-ngd-ctrl: Balance pm_runtime enablement for NGD", " - drm/amd/pm: fix smu13 power limit default/cap calculation", " - drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in", " set_soft_freq_limited_range", " - drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs", " - mailbox: Fix NULL message support in mbox_send_message()", " - vsock/virtio: fix skb overhead accounting to preserve full buf_alloc", " - net: introduce EXPORT_IPV6_MOD() and EXPORT_IPV6_MOD_GPL()", " - mptcp: pm: fix extra_subflows underflow on userspace PM subflow creation", " - vsock/virtio: fix skb overhead overflow on 32-bit builds", " - Upstream stable to v6.6.143, v6.12.94", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53132", " - vsock/virtio: fix potential unbounded skb queue", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53138", " - drm/amd/display: Bound VBIOS record-chain walk loops", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53140", " - drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53332", " - slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53156", " - nvmem: core: fix use-after-free bugs in error paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53202", " - accel/ivpu: Fix signed integer truncation in IPC receive", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53205", " - accel/ivpu: Add bounds checks for firmware log indices", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53210", " - tee: shm: fix shm leak in register_shm_helper()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-31663", " - xfrm: hold dev ref until after transport_finish NF_HOOK", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53220", " - netfilter: revalidate bridge ports", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53229", " - net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46203", " - spi: cadence-quadspi: fix unclocked access on unbind", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63871", " - Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53251", " - Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63869", " - wifi: mac80211: limit injected antenna index in", " ieee80211_parse_tx_radiotap", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53261", " - devlink: Release nested relation on devlink free", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53262", " - l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses", " - arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-45850", " - ipvs: skip ipv6 extension headers for csum checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53133", " - RDMA/umem: Fix truncation for block sizes >= 4G", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52908", " - RDMA: During rereg_mr ensure that REREG_ACCESS is compatible", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53199", " - hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53134", " - netfilter: nft_fib: fix stale stack leak via the OIFNAME register", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63883", " - serial: qcom_geni: fix kfifo underflow when flush precedes DMA", " completion IRQ", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64528", " - tty: serial: samsung: Remove redundant port lock acquisition in rx", " helpers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53329", " - drm/amd/display: Use krealloc_array() in dal_vector_reserve()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53135", " - drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53136", " - drm/amd/display: Clamp VBIOS HDMI retimer register count to array size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53137", " - drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53143", " - drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on", " GFX11", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53144", " - drm/amdkfd: fix NULL dereference in get_queue_ids()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53331", " - slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53146", " - thunderbolt: Limit XDomain response copy to actual frame size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53147", " - thunderbolt: Validate XDomain request packet size before type cast", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53148", " - thunderbolt: Clamp XDomain response data copy to allocation size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53149", " - thunderbolt: Bound root directory content to block size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53150", " - thunderbolt: Reject zero-length property entries in validator", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52929", " - sctp: stream: fully roll back denied add-stream state", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52917", " - sctp: diag: reject stale associations in dump_one path", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53154", " - mm/hugetlb: restore reservation on error in hugetlb folio copy paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53336", " - nvmem: layouts: onie-tlv: fix hang on unknown types", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53337", " - net: bonding: fix NULL pointer dereference in bond_do_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53158", " - misc: fastrpc: Fix NULL pointer dereference in rpmsg callback", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53159", " - misc: fastrpc: fix DMA address corruption due to find_vma misuse", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53160", " - misc: fastrpc: fix use-after-free race in fastrpc_map_create", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53161", " - misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52930", " - ipc/shm: serialize orphan cleanup with shm_nattch updates", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53339", " - i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53168", " - fuse: reject fuse_notify() pagecache ops on directories", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53177", " - bnxt_en: Fix NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53181", " - vsock/vmci: fix sk_ack_backlog leak on failed handshake", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53182", " - wifi: nl80211: reject oversized EMA RNR lists", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53183", " - mptcp: allow subflow rcv wnd to shrink", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63867", " - mptcp: close TOCTOU race while computing rcv_wnd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53343", " - ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53184", " - udp: clear skb->dev before running a sockmap verdict", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53185", " - zram: fix use-after-free in zram_bvec_write_partial()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53190", " - drm/virtio: fix dma_fence refcount leak on error in", " virtio_gpu_dma_fence_wait()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53194", " - USB: serial: kl5kusb105: fix bulk-out buffer overflow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53195", " - USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53196", " - USB: serial: io_ti: fix heap overflow in get_manuf_info()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52935", " - xfrm: espintcp: do not reuse an in-progress partial send", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53198", " - ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53356", " - drm/i915/gem: Fix phys BO pread/pwrite with offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53345", " - KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53208", " - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53209", " - Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53213", " - drm/vc4: fix krealloc() memory leak", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53347", " - drm/virtio: Fix driver removal with disabled KMS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43116", " - netfilter: ctnetlink: ensure safe access to master conntrack", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53214", " - ipv6: Fix a potential NPD in cleanup_prefix_route()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53217", " - net: mvpp2: sync RX data at the hardware packet offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53218", " - netfilter: nft_exthdr: fix register tracking for F_PRESENT flag", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52942", " - netfilter: nf_log: validate MAC header was set before dumping it", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53219", " - netfilter: x_tables: avoid leaking percpu counter pointers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53349", " - netfilter: nf_conntrack: destroy stale expectfn expectations on", " unregister", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52939", " - net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic", " completion", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53223", " - net: guard timestamp cmsgs to real error queue skbs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53227", " - net: openvswitch: fix possible kfree_skb of ERR_PTR", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53230", " - net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52947", " - net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53232", " - net: phy: clean the sfp upstream if phy probing fails", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53236", " - tcp: restrict SO_ATTACH_FILTER to priv users", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53350", " - ASoC: wm_adsp: Fix NULL dereference when removing firmware controls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53237", " - gpio: mvebu: fix NULL pointer dereference in suspend/resume", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53238", " - netlabel: validate unlabeled address and mask attribute lengths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53239", " - xfrm: policy: fix use-after-free on inexact bin in", " xfrm_policy_bysel_ctx()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46320", " - tap: free page on error paths in tap_get_user_xdp()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53242", " - ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked", " streams", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53352", " - signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53245", " - net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63870", " - ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53249", " - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53252", " - Bluetooth: fix memory leak in error path of hci_alloc_dev()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53253", " - Bluetooth: bnep: reject short frames before parsing", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53254", " - Bluetooth: RFCOMM: validate skb length in MCC handlers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53255", " - Bluetooth: MGMT: validate advertising TLV before type checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53256", " - Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63868", " - net: garp: fix unsigned integer underflow in garp_pdu_parse_attr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53353", " - hsr: Remove WARN_ONCE() in hsr_addr_is_self().", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53263", " - 6lowpan: fix off-by-one in multicast context address compression", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53264", " - net/sched: act_api: use RCU with deferred freeing for action lifecycle", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53265", " - dm cache policy smq: check allocation under invalidate lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53266", " - netfilter: bridge: make ebt_snat ARP rewrite writable", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53267", " - netfilter: nft_ct: bail out on template ct in get eval", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53268", " - netfilter: conntrack_irc: fix possible out-of-bounds read", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53269", " - netfilter: synproxy: add mutex to guard hook reference counting", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53270", " - ipvs: clear the svc scheduler ptr early on edit", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53273", " - tee: optee: prevent use-after-free when the client exits before the", " supplicant", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53274", " - net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53275", " - ipv6: mcast: Fix use-after-free when processing MLD queries", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52948", " - i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63898", " - USB: serial: mct_u232: fix memory corruption with small endpoint", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52910", " - bpf: Free reuseport cBPF prog after RCU grace period.", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43311", " - soc/tegra: pmc: Fix unsafe generic_handle_irq() call", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43240", " - x86/kexec: add a sanity check on previous kernel's ima kexec buffer", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-23346", " - arm64: io: Extract user memory type in ioremap_prot()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52944", " - ksmbd: fix FSCTL permission bypass by adding a permission check for", " FSCTL_SET_SPARSE", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64006", " - netfilter: nf_tables: fix dst corruption in same register operation", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547)", " - Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size", " - drm/v3d: Fix use-after-free of CPU job query arrays on error path", " - drm/v3d: Release indirect CSD GEM reference on CPU job free", " - xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit", " - net/sched: sch_sfb: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - bcache: fix uninitialized closure object", " - nfc: llcp: Fix use-after-free in llcp_sock_release()", " - nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()", " - xfrm: Check for underflow in xfrm_state_mtu", " - nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems", " - kunit: fix use-after-free in debugfs when using kunit.filter", " - netfilter: xt_cpu: prefer raw_smp_processor_id", " - vsock: keep poll shutdown state consistent", " - net: netlink: fix sending unassigned nsid after assigned one", " - net: netlink: don't set nsid on local notifications", " - net/smc: Do not re-initialize smc hashtables", " - net/iucv: fix locking in .getsockopt", " - scsi: core: Run queues for all non-SDEV_DEL devices from", " scsi_run_host_queues", " - ipv4: free net->ipv4.sysctl_local_reserved_ports after", " unregister_net_sysctl_table()", " - ALSA: pcm: oss: Fix setup list UAF on proc write error", " - ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors", " - gpio: mxc: fix irq_high handling", " - ethtool: rss: fix hkey leak when indir_size is 0", " - ASoC: codecs: simple-mux: Fix enum control bounds check", " - Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()", " - bonding: refuse to enslave CAN devices", " - ethtool: eeprom: add missing ethnl_ops_begin() / _complete() during", " fallback", " - ethtool: eeprom: add more safeties to EEPROM Netlink fallback", " - net/sched: Revert \"net/sched: Restrict conditions for adding duplicating", " netems to qdisc tree\"", " - net/handshake: Use spin_lock_bh for hn_lock", " - nvme-tcp: store negative errno in queue->tls_err", " - net/handshake: Pass negative errno through handshake_complete()", " - Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success", " - Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp", " - Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close", " - gpio: rockchip: convert bank->clk to devm_clk_get_enabled()", " - net: mana: Add NULL guards in teardown path to prevent panic on attach", " failure", " - sctp: fix race between sctp_wait_for_connect and peeloff", " - ipv6: fix possible infinite loop in rt6_fill_node()", " - ipv6: fix possible infinite loop in fib6_select_path()", " - net: skbuff: fix pskb_carve leaking zcopy pages", " - perf: Fix dangling cgroup pointer in cpuctx", " - batman-adv: tvlv: abort OGM send on tvlv append failure", " - batman-adv: tt: reject oversized local TVLV buffers", " - batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface", " - batman-adv: iv: recover OGM scheduling after forward packet error", " - batman-adv: tp_meter: avoid role confusion in tp_list", " - batman-adv: tp_meter: directly shut down timer on cleanup", " - batman-adv: tt: avoid empty VLAN responses", " - batman-adv: bla: avoid double decrement of bla.num_requests", " - media: rc: fix race between unregister and urb/irq callbacks", " - media: rc: ttusbir: fix inverted error logic", " - inet: frags: add inet_frag_queue_flush()", " - HID: core: Add printk_ratelimited variants to hid_warn() etc", " - drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register", " - drm/i915/psr: Read Intel DPCD workaround register", " - drm/dp: Add eDP 1.5 bit definition", " - drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used", " - phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X", " - batman-adv: tt: prevent TVLV entry number overflow", " - iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer", " - usb: typec: ucsi: ccg: reject firmware images without a ':' record", " header", " - usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload", " VDO", " - usb: typec: altmodes/displayport: validate count before reading Status", " Update VDO", " - usb: typec: wcove: don't write past struct pd_message in", " wcove_read_rx_buffer()", " - usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT", " - usb: typec: ucsi: validate connector number in ucsi_connector_change()", " - USB: serial: safe_serial: fix memory corruption with small endpoint", " - media: rc: igorplugusb: fix control request setup packet", " - Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free()", " - HID: quirks: Add ALWAYS_POLL quirk for SIGMACHIP USB mouse", " - Bluetooth: btusb: Allow firmware re-download when version matches", " - hpfs: fix a crash if hpfs_map_dnode_bitmap fails", " - auxdisplay: line-display: fix OOB read on zero-length message_store()", " - Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn", " - Bluetooth: HIDP: fix missing length checks in hidp_input_report()", " - Bluetooth: ISO: fix UAF in iso_recv_frame", " - Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock", " - Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync", " - Input: xpad - fix out-of-bounds access for Share button", " - parport: Fix race between port and client registration", " - USB: cdc-acm: Fix bit overlap and move quirk definitions to header", " - KVM: arm64: PMU: Preserve AArch32 counter low bits", " - KVM: SVM: Flush the current TLB when transitioning from xAVIC => x2AVIC", " - iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux", " - iio: adc: npcm: fix unbalanced clk_disable_unprepare()", " - iio: dac: max5821: fix return value check in powerdown sync", " - iio: dac: ad5686: fix input raw value check", " - iio: dac: ad5686: acquire lock when doing powerdown control", " - iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw", " - iio: gyro: itg3200: fix i2c read into the wrong stack location", " - iio: gyro: adis16260: fix division by zero in write_raw", " - iio: ssp_sensors: cancel delayed work_refresh on remove", " - iio: temperature: tsys01: fix broken PROM checksum validation", " - iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL", " - iio: light: cm3323: fix reg_conf not being initialized correctly", " - iio: buffer: hw-consumer: fix use-after-free in error path", " - USB: serial: omninet: fix memory corruption with small endpoint", " - usb: cdns3: gadget: fix request skipping after clearing halt", " - usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy", " acquisition failure", " - usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently", " leaks the runtime PM usage counter across bind/unbind cycles", " - usb: dwc2: Fix use after free in debug code", " - Input: elan_i2c - validate firmware size before use", " - wireguard: send: append trailer after expanding head", " - bpf: sockmap: fix tail fragment offset in bpf_msg_push_data", " - macsec: fix replay protection at XPN lower-PN wrap", " - ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params", " - ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().", " - ipv6: validate extension header length before copying to cmsg", " - xfrm: input: hold netns during deferred transport reinjection", " - ip6: vti: Use ip6_tnl.net in vti6_changelink().", " - HID: wacom: Fix OOB write in wacom_hid_set_device_mode()", " - iommu, debugobjects: avoid gcc-16.1 section mismatch warnings", " - nfc: hci: fix out-of-bounds read in HCP header parsing", " - xfrm: route MIGRATE notifications to caller's netns", " - xfrm: ah: use skb_to_full_sk in async output callbacks", " - ALSA: scarlett2: Fix 2i2 Gen 4 direct monitor gain on firmware 2417", " - netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without", " direction check", " - ASoC: qcom: q6asm-dai: close stream only when running", " - ASoC: qcom: q6asm-dai: do not set stream state in event and trigger", " callbacks", " - Input: xpad - add \"Nova 2 Lite\" from GameSir", " - Input: xpad - add support for ASUS ROG RAIKIRI II", " - ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops", " - Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem", " - Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490", " - comedi: comedi_test: fix check for valid scan_begin_src in", " waveform_ai_cmdtest()", " - comedi: comedi_test: Fix limiting of convert_arg in", " waveform_ai_cmdtest()", " - counter: Fix refcount leak in counter_alloc() error path", " - tty: serial: pch_uart: add check for dma_alloc_coherent()", " - usb: chipidea: core: convert ci_role_switch to local variable", " - usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval", " - USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub", " controllers", " - usb: storage: Add quirks for PNY Elite Portable SSD", " - usbip: vudc: Fix use after free bug in vudc_remove due to race condition", " - usb: usbtmc: check URB actual_length for interrupt-IN notifications", " - usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize", " - USB: serial: option: add MeiG SRM813Q", " - USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL", " - USB: serial: belkin_sa: validate interrupt status length", " - USB: serial: cypress_m8: validate interrupt packet headers", " - USB: serial: keyspan: fix missing indat transfer sanity check", " - USB: serial: mxuport: fix memory corruption with small endpoint", " - USB: serial: mct_u232: fix missing interrupt-in transfer sanity check", " - usb: gadget: uvc: hold opts->lock across XU walks in uvc_function_bind", " - usb: gadget: net2280: Fix double free in probe error path", " - usb: gadget: f_hid: fix device reference leak in hidg_alloc()", " - usb: gadget: composite: fix integer underflow in WebUSB GET_URL handling", " - usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports", " - usb: gadget: f_fs: copy only received bytes on short ep0 read", " - thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()", " - thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow", " - scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker", " - scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32", " - drm/hyperv: validate resolution_count and fix WIN8 fallback", " - drm/hyperv: validate VMBus packet size in receive callback", " - drm/i915: Fix potential UAF in TTM object purge", " - drm/amd/pm/si: Disregard vblank time when no displays are connected", " - serial: altera_jtaguart: handle uart_add_one_port() failures", " - serial: qcom-geni: fix UART_RX_PAR_EN bit position", " - serial: sh-sci: fix memory region release in error path", " - serial: zs: Fix swapped RI/DSR modem line transition counting", " - serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma", " - drm/amdkfd: fix NULL pointer bug in svm_range_set_attr", " - drm/amdkfd: fix a vulnerability of integer overflow in kfd debugger", " - drm/amdkfd: Check for pdd drm file first in CRIU restore path", " - serial: dz: Fix bootconsole message clobbering at chip reset", " - serial: dz: Fix bootconsole handover lockup", " - serial: dz: Convert to use a platform device", " - serial: zs: Fix bootconsole handover lockup", " - serial: zs: Switch to using channel reset", " - serial: zs: Convert to use a platform device", " - USB: serial: cypress_m8: fix memory corruption with small endpoint", " - USB: serial: digi_acceleport: fix memory corruption with small endpoints", " - xhci: tegra: Fix ghost USB device on dual-role port unplug", " - iommu: Skip PASID validation for devices without PASID capability", " - x86/boot: Disable stack protector for early boot code", " - rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg", " - rxrpc: Fix RESPONSE packet verification to extract skb to a linear", " buffer", " - serdev: Provide a bustype shutdown function", " - Bluetooth: hci_qca: Migrate to serdev specific shutdown function", " - Bluetooth: hci_qca: Convert timeout from jiffies to ms", " - ALSA: scarlett2: Return ENOSPC for out-of-bounds flash writes", " - ALSA: scarlett2: Allow flash writes ending at segment boundary", " - mm/memory: fix spurious warning when unmapping device-private/exclusive", " pages", " - platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery", " - net: hsr: defer node table free until after RCU readers", " - mptcp: pm: fix ADD_ADDR timer infinite retry on option space", " insufficient", " - ice: fix VF queue configuration with low MTU values", " - mptcp: cleanup fallback dummy mapping generation", " - mptcp: reset rcv wnd on disconnect", " - arm64: tlb: Flush walk cache when unsharing PMD tables", " - octeontx2-pf: avoid double free of pool->stack on AQ init failure", " - mptcp: introduce the mptcp_init_skb helper", " - mptcp: handle first subflow closing consistently", " - mptcp: do not drop partial packets", " - mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()", " - iio: chemical: scd30: Use guard(mutex) to allow early returns", " - iio: chemical: scd30: fix division by zero in write_raw", " - iio: dac: ad5686: fix ref bit initialization for single-channel parts", " - ALSA: firewire-motu: Protect register DSP event queue positions", " - usb: dwc3: xilinx: fix error handling in zynqmp init error paths", " - usb: musb: omap2430: Fix use-after-free in omap2430_probe()", " - usb: typec: ucsi: Check if power role change actually happened before", " handling", " - thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()", " - usb: typec: ucsi: Don't update power_supply on power role change if not", " connected", " - hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with", " pmbus_lock", " - hwmon: (pmbus/adm1266) serialize NVMEM blackbox read with pmbus_lock", " - hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock", " - mm: perform all memfd seal checks in a single place", " - mm/memfd: fix spelling and grammatical issues", " - memfd: deny writeable mappings when implying SEAL_WRITE", " - usb: core: Fix SuperSpeed root hub wMaxPacketSize", " - Upstream stable to v6.12.93", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43331", " - x86/kexec: Disable KCOV instrumentation after load_segments()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52943", " - net: skbuff: fix missing zerocopy reference in pskb_carve helpers", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53358", " - Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52923", " - ipc: limit next_id allocation to the valid ID range", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2025-68768", " - inet: frags: flush pending skbs in fqdir_pre_exit()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43303", " - mm/page_alloc: clear page->private in free_pages_prepare()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52934", " - batman-adv: tvlv: reject oversized TVLV packets", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52913", " - batman-adv: v: stop OGMv2 on disabled interface", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46322", " - tun: free page on build_skb failure in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46321", " - tun: free page on short-frame rejection in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52927", " - netfilter: ebtables: fix OOB read in compat_mtw_from_user", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43219", " - net: cpsw_new: Fix potential unregister of netdev that has not been", " registered yet", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-45930", " - net: mctp: ensure our nlmsg responses are initialised", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53080", " - net/sched: cls_fw: fix NULL dereference of \"old\" filters before change()", "", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Enable CONFIG_ARM64_ERRATUM_4118414", "", " * CVE-2025-10263", " - arm64: cputype: Add C1-Ultra definitions", " - arm64: cputype: Add C1-Premium definitions", "", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", "", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", "", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", "", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", "", " * CVE-2026-63886", " - scsi: target: iscsi: Validate CHAP_R length before base64 decode", "", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", "", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", "", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", "", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", "", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", "", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", "", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", "", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", "", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", "", " * CVE-2026-64000", " - net: hsr: fix potential OOB access in supervision frame handling", "", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", "", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", "", " * CVE-2026-53131", " - netfilter: require Ethernet MAC header before using eth_hdr()", "" ], "package": "linux", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:47:58 +0300" } ], "notes": "linux-headers-6.8.0-147-generic version '6.8.0-147.147' (source package linux version '6.8.0-147.147') was added. linux-headers-6.8.0-147-generic version '6.8.0-147.147' has the same source package name, linux, as removed package linux-headers-6.8.0-142. As such we can use the source package version of the removed package, '6.8.0-142.142', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-image-6.8.0-147-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-142.142", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013, 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-147.147", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 12:28:05 +0200" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-146.146", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:49:07 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-145.145", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-145.145", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Tue, 01 Sep 2026 22:50:01 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-141.141", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-141.141", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Edoardo Canepa ", "date": "Sat, 29 Aug 2026 11:37:53 +0300" } ], "notes": "linux-image-6.8.0-147-generic version '6.8.0-147.147' (source package linux-signed version '6.8.0-147.147') was added. linux-image-6.8.0-147-generic version '6.8.0-147.147' has the same source package name, linux-signed, as removed package linux-image-6.8.0-142-generic. As such we can use the source package version of the removed package, '6.8.0-142.142', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-6.8.0-147-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-147.147 -proposed tracker (LP: #2168142)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026)", " - platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug", " - selftests/bpf: Add tests for ld_{abs,ind} failure path in subprogs", " - drm/virtio: fix deadlock in display_info_cb by removing hotplug from", " dequeue worker", " - mtd: mtdswap: remove debugfs stats file on teardown", " - seqlock: Cure some more scoped_seqlock() optimization fails", " - seqlock: Allow KASAN to fail optimizing", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/umem: Add support for creating pinned DMABUF umem with a given dma", " device", " - RDMA/umem: Introduce an option to revoke DMABUF umem", " - RDMA/umem: Add ib_umem_dmabuf_get_pinned_and_lock helper", " - RDMA/umem: Move umem dmabuf revoke logic into helper function", " - RDMA/umem: Add pinned revocable dmabuf import interface", " - RDMA/umem: Add helpers for umem dmabuf revoke lock", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - selftests/alsa: Fix memory leak in find_controls error path", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: cs42l43: Correct report for forced microphone jack", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - sched/vtime: Get rid of generic vtime_task_switch() implementation", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - can: j1939: fix lockless local-destination check", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - crypto: rsa-pkcs1pad: Don't WARN on an empty digest", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - wifi: ath11k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - wifi: ath12k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - ASoC: cs35l56: Don't use devres to unregister component", " - ASoC: cs35l56: Fix potential probe() deadlock", " - ASoC: cs35l56: Use complete_all() to signal init_completion", " - wifi: iwlwifi: mvm: validate SAR GEO response payload size", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - hwmon: (asus-ec-sensors) fix looping over banks while reading from EC", " - hwmon: (asus-ec-sensors) fix EC read intervals", " - hwmon: (asus-ec-sensors) add missed handle for ENOMEM", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - pds_core: yield the CPU while waiting for the adminq to drain", " - pds_core: order completion reads after the ownership check", " - pds_core: check for workqueue allocation failure", " - tls: device: push pending open record on splice EOF", " - selftest: af_unix: Add Kconfig file.", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - amt: make the head writable before rewriting the L2 header", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: dpaa: fix mode setting", " - iomap: correct the range of a partial dirty clear", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - net: stmmac: enable the MAC on link up for all supported speeds", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - ppp: use IFF_NO_QUEUE in virtual interfaces", " - ppp: convert to percpu netstats", " - ppp: enable TX scatter-gather", " - ppp: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: fix LAG recipe to profile association", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't", " at 0 (v2)", " - drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nxp: imx8-isi: Clean up already-initialized pipes on probe", " failure", " - media: nxp: imx8-isi: Fix missing v4l2_subdev_cleanup() in pipe init", " error path", " - media: nxp: imx8-isi: Fix scale factor calculation for hardware rounding", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vivid: add vivid_update_reduced_fps()", " - media: vpif_capture: fix OF node reference imbalance", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - LoongArch: Fix oops during single-step debugging", " - x86/boot/compressed: Disable jump tables", " - serial: sc16is7xx: implement gpio get_direction() callback", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - ice: use READ_ONCE() to access cached PHC time", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amd/display: Fix dcn32 DTB DTO update breaking live pixel rate", " sources", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - net: pcs: xpcs: fix SGMII state reading", " - bpf: drop bpf_lsm_getselfattr from hook list", " - udmabuf: Do not create malformed scatterlists", " - i2c: davinci: Unregister cpufreq notifier on probe failure", " - VFS/audit: introduce kern_path_parent() for audit", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - rxrpc: Pull out certain app callback funcs into an ops table", " - fbcon: Rename struct fbcon_ops to struct fbcon_par", " - fbcon: Use correct type for vc_resize() return value", " - rxrpc: Don't need barrier for ->tx_bottom and ->acks_hard_ack", " - rxrpc: Use irq-disabling spinlocks between app and I/O thread", " - rxrpc: Fix notification vs call-release vs recvmsg", " - rxrpc: Fix socket notification race", " - vduse: Use fixed 4KB bounce pages for non-4KB page size", " - vduse: remove unused vaddr parameter of vduse_domain_free_coherent", " - vduse: take out allocations from vduse_dev_alloc_coherent", " - octeontx2: Annotate mmio regions as __iomem", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - fbdev/efifb: Replace references to global screen_info by local pointer", " - ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable()", " - ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe()", " - ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb", " - ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - netfilter: nft_set_pipapo: use GFP_KERNEL for insertions", " - netfilter: nft_set_pipapo: move prove_locking helper around", " - netfilter: nft_set_pipapo: make pipapo_clone helper return NULL", " - netfilter: nft_set_pipapo: prepare walk function for on-demand clone", " - netfilter: nft_set_pipapo: merge deactivate helper into caller", " - netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone", " - netfilter: nft_set_pipapo: move cloning of match info to insert/removal", " path", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_tables: Remove unused nft_reduce_is_readonly()", " - netfilter: nf_tables: remove register tracking infrastructure", " - NFSD: pass nfsd_file to nfsd_iter_read()", " - sunrpc: allocate a separate bvec array for socket sends", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - dma: dw-edma: Fix build warning in dw_edma_pcie_probe()", " - dmaengine: dw-edma: Fix confusing cleanup.h syntax", " - platform/x86: dell-smbios: Move request functions for reuse", " - i2c: imx: separate atomic, dma and non-dma use case", " - nfs: remove dead code for the old swap over NFS implementation", " - ovl: use linked upper dentry in copy-up tmpfile", " - bootconfig: do not put quotes on cmdline items unless necessary", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - rxrpc: Disable IRQ, not BH, to take the lock for ->attend_link", " - netfilter: nft_quota: use atomic64_xchg for reset", " - soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE", " - wifi: cfg80211: pass net_device to .set_monitor_channel", " - wifi: cfg80211: define and use wiphy guard", " - wifi: cfg80211: derive S1G beacon TSF from S1G fields", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - smb: move some duplicate definitions to common/cifsglob.h", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - wifi: mt76: mt7925: extend mt7925_mcu_bss_he_tlv for per-link BSS", " - ovl: fix trusted xattr escape prefix matching", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - dpll: add clock quality level attribute and op", " - net/mlx5: DPLL, Add clock quality level op implementation", " - net/mlx5: Remove newline at the end of a netlink error message", " - net/mlx5: Refactor EEPROM query error handling to return status", " separately", " - octeontx2-pf: tc: fix egress ratelimiting", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm/displayid: move drm_displayid.h to drm_displayd_internal.h", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - ALSA: timer: drain a slave's callback before its master detaches it", " - ALSA: timer: don't re-enter an instance callback that is still running", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - sysctl: treewide: constify ctl_table_header::ctl_table_arg", " - ceph: fix refcount leak in ceph_readdir()", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - net: move skb_gro_receive_list from udp to core", " - net: add pskb_may_pull() to skb_gro_receive_list()", " - vsock/virtio: collapse receive queue under memory pressure", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - xfs: add an explicit owner field to xfs_da_args", " - xfs: factor out xfs_attr3_leaf_init", " - xfs: don't replace the wrong part of the cow fork", " - rxrpc: Fix CPU time starvation in I/O thread", " - ASoC: mediatek: mt8183-afe-pcm: Shorten memif_data table using macros", " - ASoC: mediatek: mt8183-afe-pcm: Support >32 bit DMA addresses", " - tcp: Decrement tcp_md5_needed static branch", " - nvmet: Introduce nvmet_req_transfer_len()", " - block: add helper add_disk_final()", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections", " - Bluetooth: hci_core: Fix not accounting for BIS/CIS/PA links separately", " - afs: Improve server refcount/active count tracing", " - afs: Make afs_lookup_cell() take a trace note", " - afs: Drop the net parameter from afs_unuse_cell()", " - rxrpc: Allow the app to store private data on peer structs", " - afs: Use the per-peer app data provided by rxrpc", " - afs: Fix afs_server ref accounting", " - afs: Simplify cell record handling", " - afs: Fix dynamic lookup to fail on cell lookup failure", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - lib/string_choices: Add str_plural() helper", " - USB: gadget: Use str_enable_disable-like helpers", " - usb: musb: omap2430: clean up probe error handling", " - net/mlx5e: Fix NULL pointer dereference in ioctl module EEPROM query", " - rxrpc: Fix locking issues with the peer record hash", " - wifi: nl80211: fix nl80211_start_radar_detection return value", " - afs: Set vllist to NULL if addr parsing fails", " - dpll: fix clock quality level reporting", " - afs: Fix delayed allocation of a cell's anonymous key", " - afs: handle CB.InitCallBackState3 requests without a server record", " - Bluetooth: hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK", " - Bluetooth: hci_conn: Fix not cleaning up Broadcaster/Broadcast Source", " - Bluetooth: hci_conn: Remove redundant memset after kzalloc", " - Bluetooth: hci_conn: Fix not cleaning up PA_LINK connections", " - Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()", " - afs: Fix uninit var in afs_alloc_anon_key()", " - Upstream stable to v6.6.148, v6.12.101", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72168", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72213", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72244", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53078", " - bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2025-40098", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_get_acpi_mute_state()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68372", " - usb: core: port: Deattach Type-C connector on component unbind", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72175", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45901", " - netfilter: nf_tables: revert commit_mutex usage in reset path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45897", " - netfilter: nft_counter: serialize reset with spinlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72015", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72017", " - net: macb: drop in-flight Tx SKBs on close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72030", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72023", " - octeontx2-pf: fix SQB pointer leak on init failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72040", " - ipmi: fix refcount leak in i_ipmi_request()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72045", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72062", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72051", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72070", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72142", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72147", " - dmaengine: dw-edma-pcie: Reject devices without driver data", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72254", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72253", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72260", " - ASoC: mediatek: mt8192: Check runtime resume during probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72305", " - VDUSE: avoid leaking information to userspace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64205", " - i2c: i801: fix hardware state machine corruption in error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64280", " - fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72146", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72124", " - can: isotp: serialize TX state transitions under so->rx_lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72125", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72115", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72117", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72116", " - can: bcm: fix stale rx/tx ops after device removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72113", " - can: bcm: add missing device refcount for CAN filter removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72114", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72119", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72118", " - can: bcm: fix CAN frame rx/tx statistics", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72121", " - can: bcm: add locking when updating filter and timer values", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53090", " - bpf: Fix ld_{abs,ind} failure path analysis in subprogs", "", " * test_vxlan_vnifiltering.sh from ubuntu_kselftests_net failed on linux-", " oem-6.8 (with ipv6 default rdst) (LP: #2071590)", " - selftests: net: use slowwait to make sure IPv6 setup finished", "", " * ubuntu_bpf failed to build in noble (error: redefinition of", " 'stack_load_preserves_const_precision') (LP: #2160493)", " - SAUCE: Revert \"selftests/bpf: validate fake register spill/fill", " precision backtracking logic\"", "", " * CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", "", " * Backport: \"mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios\"", " (LP: #2162917)", " - mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios", "", " * qrtr: ns: node limit of 64 breaks QRTR routing on large multi-node", " deployments (LP: #2165140)", " - net: qrtr: ns: Raise node count limit to 512", "", " * [UBUNTU 24.04] kernel: CPU hotplug unsupported by CPUMF (LP: #2165732)", " - s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks", "", " * CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", "", " * CVE-2025-38563", " - perf/core: Prevent VMA split of buffer mappings", "", " * CVE-2025-38565", " - perf/core: Exit early on perf_mmap() fail", "", " * CVE-2025-38187", " - drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()", "", " * CVE-2025-38069", " - PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops", "", " * CVE-2025-40014", " - objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()", "", " * CVE-2025-21985", " - drm/amd/display: Fix out-of-bound accesses", "", " * CVE-2024-56552", " - drm/xe/guc_submit: fix race around suspend_pending", "", " * CVE-2025-21687", " - vfio/platform: check the bounds of read/write syscalls", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237)", " - ext4: fix fd leak in EXT4_IOC_MOVE_EXT cross-sb validation", " - mm: refactor mm_access() to not return NULL", " - Upstream stable to v6.6.146, v6.12.98, v6.6.147, v6.12.99, v6.12.100", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237) //", " CVE-2026-64560", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995)", " - bpf, arm64: Reject out-of-range B.cond targets", " - nfsd: release layout stid on setlease failure", " - Bluetooth: btmtk: apply the common btmtk_fw_get_filename", " - Bluetooth: btmtk: Fix failed to send func ctrl for MediaTek devices.", " - Bluetooth: btmtk: Fix wait_on_bit_timeout interruption during shutdown", " - userfaultfd: gate must_wait writability check on pte_present()", " - perf: Fix dangling cgroup pointer in cpuctx backport", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error", " - device property: initialize the remaining fields of fwnode_handle in", " fwnode_init()", " - f2fs: validate orphan inode entry count", " - f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode", " - f2fs: fix potential deadlock in f2fs_balance_fs()", " - f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()", " - f2fs: fix listxattr handling of corrupted xattr entries", " - block: Avoid mounting the bdev pseudo-filesystem in userspace", " - i2c: core: fix irq domain leak on adapter registration failure", " - i2c: core: fix hang on adapter registration failure", " - i2c: core: fix NULL-deref on adapter registration failure", " - i2c: core: fix adapter debugfs creation", " - fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()", " - NFSv4/flexfiles: reject zero filehandle version count", " - locking/rtmutex: Make sure we wake anything on the wake_q when we", " release the lock->wait_lock", " - bonding: fix xfrm offload feature setup on active-backup mode", " - mm/vmscan: flush deferred TLB before freeing large folios", " - perf trace beauty fcntl: Fix build with older kernel headers", " - ACPI: CPPC: Suppress UBSAN warning caused by field misuse", " - ACPI: NFIT: core: Fix possible NULL pointer dereference", " - perf/core: Detach event groups during remove_on_exec", " - arm64: sysreg: Add layout for ID_AA64MMFR4_EL1", " - virtio_net: Support dynamic rss indirection table size", " - LoongArch: Add PIO for early access before ACPI PCI root register", " - usb: gadget: function: rndis: add length check to response query", " - usb: gadget: function: rndis: add length check for header", " - iio: accel: bmc150: clamp the device-reported FIFO frame count", " - iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error", " - iio: adc: lpc32xx: Initialize completion before requesting IRQ", " - iio: adc: ti-ads124s08: Return reset GPIO lookup errors", " - iio: chemical: scd30: Cleanup initializations and fix sign-extension bug", " - iio: event: Fix event FIFO reset race", " - iio: gyro: bmg160: bail out when bandwidth/filter is not in table", " - iio: gyro: bmg160: wait full startup time after mode change at probe", " - iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ", " - iio: imu: st_lsm6dsx: deselect shub page before reading whoami", " - iio: light: al3010: fix incorrect scale for the highest gain range", " - iio: light: gp2ap002: fix runtime PM leak on read error", " - iio: light: opt3001: fix missing state reset on timeout", " - iio: light: tsl2591: return actual error from probe IRQ failure", " - iio: light: veml6030: fix channel type when pushing events", " - iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call", " - iio: temperature: ltc2983: Fix reinit_completion() called after", " conversion start", " - ALSA: virtio: Add missing 384 kHz PCM rate mapping", " - ALSA: ymfpci: check snd_ctl_new1() return value", " - ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input", " parser", " - ALSA: cmipci: check snd_ctl_new1() return value", " - ALSA: es1938: check snd_ctl_new1() return value", " - ALSA: firewire: isight: bound the sample count to the packet payload", " - ALSA: gus: check snd_ctl_new1() return value", " - ALSA: ice1712: check snd_ctl_new1() return value", " - ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()", " - ALSA: usb-audio: avoid kobject path lookup in DualSense match", " - ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()", " - ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch", " put callbacks", " - ALSA: usb-audio: Update Babyface Pro control caches only after", " successful writes", " - ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful", " writes", " - vfio/pci: Use a private flag to prevent power state change with VFs", " - vfio/pci: Latch disable_idle_d3 per device", " - vfio/pci: Release the VGA arbiter client on register_device() failure", " - vfio/pci: Fix racy bitfields and tighten struct layout", " - vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc", " - Bluetooth: btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB", " - Bluetooth: btusb: fix use-after-free on registration failure", " - Bluetooth: btusb: fix use-after-free on marvell probe failure", " - Bluetooth: btusb: fix wakeup source leak on probe failure", " - binder: fix UAF in binder_thread_release()", " - binder: fix UAF in binder_free_transaction()", " - usb: xhci: Fix sleep in atomic context in xhci_free_streams()", " - PCI: altera: Do not dispose parent IRQ mapping", " - mm/damon/ops-common: handle extreme intervals in damon_hot_score()", " - netfilter: ipset: fix race between dump and ip_set_list resize", " - virtio-mmio: fix device release warning on module unload", " - hwrng: virtio: clamp device-reported used.len at copy_data()", " - USB: chaoskey: Fix slab-use-after-free in chaoskey_release()", " - usb: dwc3: run gadget disconnect from sleepable suspend context", " - 6lowpan: fix NHC entry use-after-free on error path", " - tipc: fix out-of-bounds read in broadcast Gap ACK blocks", " - staging: vme_user: bound slave read/write to the kern_buf size", " - smb: client: restrict implied bcc[0] exemption to responses without data", " area", " - staging: vme_user: fix location monitor leak in fake bridge", " - staging: vme_user: fix location monitor leak in tsi148 bridge", " - media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe", " - staging: media: atomisp: reduce load_primary_binaries() stack usage", " - staging: rtl8723bs: fix heap buffer overflow in", " rtw_cfg80211_set_wpa_ie()", " - staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()", " - staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop", " - staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop", " - staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and", " join_cmd_hdl()", " - staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop", " - staging: rtl8723bs: fix OOB write in HT_caps_handler()", " - crypto: amlogic - avoid double cleanup in meson_crypto_probe()", " - ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then", " SMB2_CANCEL", " - net: af_key: initialize alg_key_len for IPComp states", " - audit: Fix data races of skb_queue_len() readers on audit_queue", " - Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete", " - debugobjects: Plug race against a concurrent OOM disable", " - fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns", " - NTB: epf: Avoid calling pci_irq_vector() from hardirq context", " - io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item", " - ipv4: igmp: remove multicast group from hash table on device destruction", " - net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes", " - mfd: cros_ec: Delay dev_set_drvdata() until probe success", " - mm: shrinker: fix NULL pointer dereference in debugfs", " - netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump", " - f2fs: bound i_inline_xattr_size for non-inline-xattr inodes", " - drm/amd: Fix set but not used warnings", " - apparmor: advertise the tcp fast open fix is applied", " - nfsd: move name lookup out of nfsd4_list_rec_dir()", " - nfsd: change nfs4_client_to_reclaim() to allocate data", " - arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative", " - arm64: Fix early handling of FEAT_E2H0 not being implemented", " - KVM: arm64: Initialize HCR_EL2.E2H early", " - arm64: Revamp HCR_EL2.E2H RES1 detection", " - arm64: sysreg: Correct sign definitions for EIESB and DoubleLock", " - iio: adc: spear: Initialize completion before requesting IRQ", " - iio: imu: inv_icm42600: fix timestamp clock period by using lower value", " - ALSA: usb-audio: Roll back quirk control caches on write errors", " - usb: typec: tcpci_rt1711h: unregister TCPCI port with devres", " - gpio: eic-sprd: use raw_spinlock_t in the irq startup path", " - netfilter: ebtables: module names must be null-terminated", " - netfilter: ebtables: terminate table name before find_table_lock()", " - Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()", " - Bluetooth: bnep: pin L2CAP connection during netdev registration", " - Bluetooth: btnxpuart: Fix out-of-bounds firmware read in", " nxp_recv_fw_req_v3()", " - Bluetooth: fix UAF in bt_accept_dequeue()", " - Bluetooth: L2CAP: validate option length before reading conf opt value", " - fs/ntfs3: fsync files by syncing parent inodes", " - fs/ntfs3: zero-fill folios beyond i_valid in ntfs_read_folio()", " - fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()", " - coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer()", " - smb/client: Fix error code in smb2_aead_req_alloc()", " - ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE", " - ksmbd: add a permission check for FSCTL_SET_ZERO_DATA", " - ksmbd: serialize QUERY_DIRECTORY requests per file", " - ksmbd: require source read access for duplicate extents", " - ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock", " cancellation", " - ksmbd: add a WRITE_DAC/WRITE_OWNER check to SMB2 SET_INFO SECURITY", " - ksmbd: run set info with opener credentials", " - ksmbd: enforce FILE_READ_ATTRIBUTES on SMB_FIND_FILE_POSIX_INFORMATION", " - ksmbd: add per-handle permission check to FILE_LINK_INFORMATION", " - ksmbd: use opener credentials for delete-on-close", " - smb: client: fix query directory replay double-free", " - smb: client: fix query_info() replay double-free", " - smb: client: fix double-free in SMB2_ioctl() replay", " - smb: client: fix change notify replay double-free", " - smb: client: fix double-free in SMB2_flush() replay", " - smb: client: fix double-free in SMB2_open() replay", " - smb: client: fix double-free in SMB2_close() replay", " - smb: client: Fix next buffer leak in receive_encrypted_standard()", " - smb: client: use unaligned reads in parse_posix_ctxt()", " - smb: client: harden POSIX SID length parsing", " - smb: client: mask server-provided mode to 07777 in modefromsid", " - OPP: of: Fix potential memory leak in opp_parse_supplies()", " - firmware_loader: fix device reference leak in firmware_upload_register()", " - cpufreq: intel_pstate: Sync policy->cur during CPU offline", " - sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT", " - cpufreq: Fix hotplug-suspend race during reboot", " - cpufreq: pcc: fix use-after-free and double free in _OSC evaluation", " - posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path", " - clocksource/drivers/timer-tegra186: Fix support for multiple watchdog", " instances", " - X.509: Fix validation of ASN.1 certificate header", " - tools/mm/slabinfo: Fix trace disable logic inversion", " - tools/mm/slabinfo: fix total_objects attribute name", " - HID: wacom: stop hardware after post-start probe failures", " - HID: letsketch: fix UAF on inrange_timer at driver unbind", " - HID: lg-g15: cancel pending work on remove to fix a use-after-free", " - HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte", " reads", " - hfs/hfsplus: zero-initialize buffer in hfs_bnode_read", " - nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers", " - media: mtk-jpeg: cancel workqueue on release for supported platforms", " only", " - xfs: use null daddr for unset first bad log block", " - xfs: fix unreachable BIGTIME check in dquot flush validation", " - bpf: Reject fragmented frames in devmap", " - bpf: Restore sysctl new-value from 1 to 0", " - net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()", " - usb: cdc_acm: Add quirk for Uniden BC125AT scanner", " - usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()", " - USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub", " - usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()", " - usb: free iso schedules on failed submit", " - usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler", " - usb: gadget: udc: Fix use-after-free in gadget_match_driver", " - usb: gadget: f_printer: take kref only for successful open", " - USB: idmouse: fix use-after-free on disconnect race", " - USB: ldusb: fix use-after-free on disconnect race", " - USB: iowarrior: fix use-after-free on disconnect", " - USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD", " - USB: legousbtower: fix use-after-free on disconnect race", " - usb: sl811-hcd: disable controller wakeup on remove", " - USB: storage: include US_FL_NO_SAME in quirks mask", " - USB: misc: uss720: unregister parport on probe failure", " - usb: mtu3: unmap request DMA on queue failure", " - USB: serial: keyspan_pda: fix information leak", " - USB: serial: option: add Telit Cinterion FE990D50 compositions", " - USB: serial: digi_acceleport: fix broken rx after throttle", " - USB: serial: digi_acceleport: fix hard lockup on disconnect", " - USB: serial: digi_acceleport: fix write buffer corruption", " - USB: ulpi: fix memory leak on registration failure", " - USB: usb-storage: ene_ub6250: restore media-ready check", " - usbip: tools: support SuperSpeedPlus devices", " - usbip: vudc: fix NULL deref in vep_dequeue()", " - usb: typec: anx7411: use devm_pm_runtime_enable()", " - usb: typec: class: drop PD lookup reference", " - usb: typec: tcpm: Validate SVID index in svdm_consume_modes()", " - usb: typec: ucsi: Invert DisplayPort role assignment", " - usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt", " mode", " - usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove", " - usb: typec: ucsi: cancel pending work on system suspend", " - iio: temperature: ltc2983: Fix n_wires default bypassing rotation check", " - PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining", " - udf: validate free block extents against the partition length", " - udf: validate VAT header length against the VAT inode size", " - udf: validate sparing table length as an entry count, not a byte count", " - hwrng: jh7110 - fix refcount leak in starfive_trng_read()", " - dm-ioctl: report an error if a device has no table", " - nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace", " disks", " - btrfs: do not trim a device which is not writeable", " - partitions: aix: bound the pp_count scan to the ppe array", " - isofs: bound Rock Ridge symlink components to the SL record", " - crypto: af_alg - Remove zero-copy support from skcipher and aead", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps again", " - crypto: ecc - Fix carry overflow in vli multiplication", " - crypto: pcrypt - restore callback for non-parallel fallback", " - crypto: drbg - Fix returning success on failure in CTR_DRBG", " - crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels", " - crypto: drbg - Fix the fips_enabled priority boost", " - crypto: qat - validate RSA CRT component lengths", " - crypto: talitos - use dma_sync_single_for_cpu() before reading", " descriptor header", " - crypto: talitos - add chaining of arbitrary number of descriptor for the", " SEC1", " - crypto: talitos - move dma unmapping code in flush_channel() into a", " standalone dma_unmap_request() function", " - crypto: talitos - move dma mapping code in talitos_submit() into a", " standalone dma_map_request() function", " - crypto: talitos - move code in current_desc_hdr() into a standalone", " function", " - crypto: talitos/hash - prepare SEC1 descriptor chaining, remove", " additional descriptor", " - crypto: talitos/hash - use descriptor chaining for SEC1 instead of", " workqueue", " - crypto: talitos/hash - drop workqueue mechanism for SEC1", " - crypto: talitos/hash - rename first_desc/last_desc to", " first_request/last_request", " - crypto: talitos/hash - remove useless wrapper", " - crypto: talitos/hash - fix SEC2 64k - 1 ahash request limitation", " - arm64: fpsimd: Fix type mismatch in sme_{save,load}_state()", " - spi: fsl-lpspi: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - spi: fsl-lpspi: terminate the RX channel on TX prepare failure path", " - EDAC/i10nm: Don't fail probing if ADXL is missing", " - watchdog: apple: Add \"apple,t8103-wdt\" compatible", " - tracing: Prevent out-of-bounds read in glob matching", " - NFSv4: include MAY_WRITE in open permission mask for O_TRUNC", " - module: decompress: check return value of module_extend_max_pages()", " - exfat: bound uniname advance in exfat_find_dir_entry()", " - NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()", " - KVM: VMX: Refresh GUEST_PENDING_DBG_EXCEPTIONS.BS on all injected #DBs", " - KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest", " mode", " - udmabuf: fix DMA direction mismatch in release_udmabuf()", " - i2c: core: fix adapter deregistration race", " - i2c: mpc: Fix timeout calculations", " - i2c: stm32f7: truncate clock period instead of rounding it", " - Input: synaptics-rmi4 - unregister function handlers on physical driver", " registration failure", " - Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count", " - Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count", " - Input: elan_i2c - prevent division by zero and arithmetic underflow", " - Input: goodix - clamp the device-reported contact count", " - Input: iforce - bound the device-reported force-feedback effect index", " - Input: mms114 - fix touch indexing for MMS134S and MMS136", " - Input: touchwin - reset the packet index on every complete packet", " - Input: mms114 - reject an oversized device packet size", " - Input: maplemouse - fix NULL pointer dereference in open()", " - Input: mms114 - fix multi-touch slot corruption", " - Input: maple_keyb - set driver data before registering input device", " - Input: maplemouse - set driver data before registering input device", " - Input: maplecontrol - set driver data before registering input device", " - RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", " - fuse: fix device node leak in cuse_process_init_reply()", " - fuse: re-lock request before returning from fuse_ref_folio()", " - smb: client: reject overlapping data areas in SMB2 responses", " - xfs: fail recovery on a committed log item with no regions", " - xfs: resample the data fork mapping after cycling ILOCK", " - smb/server: do not require delete access for non-replacing links", " - sched/fair: Only update stats for allowed CPUs when looking for dst", " group", " - KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU", " - KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove CRYPTO_DEV_SUN4I_SS_PRNG", " - crypto: crypto4xx - Remove ahash-related code", " - bpf: Support for hardening against JIT spraying", " - x86/bugs: Enable IBPB flush on BPF JIT allocation", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix sequence number when no EOF", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - dt-bindings: power: imx93: Add MIPI PHY power domain", " - serial: msm: Disable DMA for kernel console UART", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: Fix further netns teardown to cancel the preallocation charger", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/amdgpu: fix integer overflow in amdgpu_gem_align_pitch()", " - drm/radeon: fix integer overflow in radeon_align_pitch()", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " - libbpf: Report error when a negative kprobe offset is specified", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg", " warning", " - wifi: cfg80211: fix grammar in MLO group key error message", " - arm64: tegra: Fix Tegra234 MGBE PTP clock", " - dt-bindings: pinctrl: nvidia,tegra234: Add missing required block", " - drm/amdkfd: Validate CRIU-restored IDs before idr_alloc", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sama5d4_wdt: Fix WDDIS detection on SAM9X60 and SAMA7G5", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - media: v4l2-common: Add YUV24 format info", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " - dlm: fix add msg handle in send_queue ordered", " - nilfs2: fix backing_dev_info reference leak", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - evm: terminate and bound the evm_xattrs read buffer", " - thermal: hwmon: Fix critical temperature attribute removal", " - clk: scpi: Unregister child clock providers on remove", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - spi: hisi-kunpeng: Use dev_err_probe() for host registration failure", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/srpt: fix integer overflow in immediate data length check", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - driver core: Use mod_delayed_work to prevent lost deferred probe work", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - bus: sunxi-rsb: Always check register address validity", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: seq: midi: Serialize output teardown with event_input", " - pinctrl: cs42l43: Fix polarity on debounce", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " - drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X", " client is registered", " - drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove", " - gpu: host1x: Allow entries in BO caches to be freed", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - gpu: host1x: Fix iommu_map_sgtable() return value check", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Harden parse_vma_segs() path parsing", " - libbpf: Fix UAF in strset__add_str()", " - dax/kmem: account for partial discontiguous resource upon removal", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - rpmsg: use generic driver_override infrastructure", " - md/raid10: reset read_slot when reusing r10bio for discard", " - RDMA/siw: bound Read Response placement to the RREAD length", " - block: skip sync_blockdev() on surprise removal in bdev_mark_dead()", " - crypto: algif_skcipher - force synchronous processing", " - crypto: crypto4xx - Remove insecure and unused rng_alg", " - crypto: hisi-trng - Remove crypto_rng interface", " - bpf: Restrict JIT predictor flush to cBPF", " - bpf: Skip redundant IBPB in pack allocator", " - bpf: Prefer packs that won't trigger an IBPB flush on allocation", " - bpf: Prefer dirty packs for eBPF allocations", " - clk: scmi: Fix clock rate rounding", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - bitops: use common function parameter names", " - media: rockchip: rga: fix too small buffer size", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - scsi: ufs: Fix wrong value printed in unexpected UPIU response case", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " - mm/fake-numa: fix under-allocation detection in uniform split", " - ext2: fix ignored return value of generic_write_sync()", " - sched: restore timer_slack_ns when resetting RT policy on fork", " - lib/test_meminit: use && for bools", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: reject FITRIM ranges shorter than a cluster", " - ocfs2/dlm: require a ref for locking_state debugfs open", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - bpf: Check tail zero of bpf_prog_info", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - wifi: wcn36xx: fix heap overflow from oversized firmware HAL response", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " - wifi: wcn36xx: fix OOB read from short trigger BA firmware response", " - ALSA: seq: Fix partial userptr event expansion", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - scsi: target: Fix hexadecimal CHAP_I handling", " - scsi: target: Remove tcm_loop target reset handling", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " - hwspinlock: qcom: avoid uninitialized struct members", " - sched/fair: Fix cpu_util runnable_avg arithmetic", " - wifi: mt76: fix argument to ieee80211_is_first_frag()", " - wifi: mt76: mt7915: fix potential tx_retries underflow", " - wifi: mt76: mt7921: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - spi: meson-spifc: fix runtime PM leak on remove", " - ASoC: codecs: aw88261: fix incorrect masks for boost regs", " - vduse: hold vduse_lock across IDR lookup in open path", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " - vduse: Requeue failed read to send_list head", " - vhost/net: complete zerocopy ubufs only once", " - tools/virtio: check mmap return value in vringh_test", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - bonding: 3ad: fix mux port state on oper down", " - ext4: fix kernel BUG in ext4_write_inline_data_end", " - selftests/bpf: Fix bpf_iter/task_vma test", " - cxl/test: Fix integer overflow in mock LSA bounds checks", " - cxl/test: Zero out LSA backing memory to avoid leaking to user", " - of: cpu: add check in __of_find_n_match_cpu_property()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " - RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " - ASoC: fsl: fsl_audmix: Validate written enum values", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " - net/sched: cls_flow: Dont expose folded kernel pointers", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " - bridge: cfm: reject invalid CCM interval at configuration time", " - sctp: validate embedded address parameter length", " - net/sched: sch_hfsc: Don't make class passive twice", " - tipc: require net admin for TIPCv2 netlink mutators", " - tipc: prevent snt_unacked underflow on CONN_ACK", " - tipc: reject inverted service ranges from peer bindings", " - cxl/test: Add check after kzalloc() memory in alloc_mock_res()", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " - crypto: rng - Free default RNG on module exit", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - power: supply: core: fix supplied_from allocations", " - handshake: Require admin permission for DONE command", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - net: wwan: t7xx: check skb_clone in control TX", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - netfilter: nf_conncount: callers must hold rcu read lock", " - ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait()", " - cifs: remove all cifs files before kill super", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - tipc: fix UAF in tipc_l2_send_msg()", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - ionic: Fix check in ionic_get_link_ext_stats", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - coresight: cti: Fix DT filter signals silently ignored", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - PCI/ASPM: Don't reconfigure ASPM entering low-power state", " - PCI: Introduce named defines for PCI ROM", " - PCI: Check ROM header and data structure addr before accessing", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - mailbox: mtk-adsp: fix UAF during device teardown", " - staging: most: video: avoid double free on video register failure", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " - iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " - iio: tcs3472: power down chip on probe failure", " - clk: at91: keep securam node alive while mapping it", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - fs/ntfs3: add bounds check to run_get_highest_vcn()", " - fs/ntfs3: fix mount failure on 64K page-size kernels", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - pNFS/filelayout: fix cheking if a layout is striped", " - xprtrdma: Remove temp allocation of rpcrdma_rep objects", " - xprtrdma: Avoid 250 ms delay on backlog wakeup", " - xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot", " - xprtrdma: Post receive buffers after RPC completion", " - xprtrdma: Use sendctx DMA state for Send signaling", " - xprtrdma: Decouple req recycling from RPC completion", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - nfs: keep PG_UPTODATE clear after read errors in page groups", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Fix bcall rep leak and unbounded peek", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - apparmor: fix rawdata_f_data implicit flex array", " - apparmor: fix potential UAF in aa_replace_profiles", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - sparc: led: avoid trimming a newline from empty writes", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - spi: dw: fix wrong BAUDR setting after resume", " - xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO", " path", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " - PCI: iproc: Restore .map_irq() for the platform bus driver", " - spi: rpc-if: Use correct device for hardware reinitialization on resume", " - virtio-net: fix len check in receive_big()", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - flow_dissector: check device type before reading ETH_ADDRS", " - ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: Fix data race between add and dump in all hash types", " - netfilter: ipset: annotate \"pos\" for concurrent readers/writers", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash", " types", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - irqchip/crossbar: Fix parent domain resource leak", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - net: marvell: prestera: initialize err in prestera_port_sfp_bind", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " - net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths", " - octeontx2-af: mcs: Fix unsupported secy stats read", " - octeontx2-pf: Clear stats of all resources when freeing resources", " - octeontx2-pf: mcs: Fix mcs resources free on PF shutdown", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: Fix stack slot index in nospec checks", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()", " - ice: fix AQ error code comparison in ice_set_pauseparam()", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - ipv4: fib: Don't ignore error route in local/main tables.", " - bpf, lsm: Add disabled BPF LSM hook list", " - bpf: Disable xfrm_decode_session hook attachment", " - netfilter: nf_nat: avoid invalid nat_net pointer use on failed", " nf_nat_init()", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - netfilter: nft_compat: ebtables emulation must reject non-bridge targets", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - NTB: epf: Report 0-based doorbell vector via ntb_db_event()", " - NTB: epf: Fix doorbell bitmask and IRQ vector handling", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - net, bpf: check master for NULL in xdp_master_redirect()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - net: mvneta: re-enable percpu interrupt on resume", " - net: sungem: fix probe error cleanup", " - net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - net: enetc: check the number of BDs needed for xdp_frame", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - apparmor: check label build before no_new_privs test", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - net/sched: sch_teql: Introduce slaves_lock to avoid race condition and", " UAF", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - cxgb4: Fix decode strings dump for T6 adapters", " - virtio_net: disable cb when NAPI is busy-polled", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - ksmbd: reject undersized DACLs before parsing ACEs", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - pinctrl: meson: restore non-sleeping GPIO access", " - net/sched: hhf: clear heavy-hitter state on reset", " - fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid", " - afs: Fix error code in afs_extract_vl_addrs()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix vllist leak", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " - afs: Fix unchecked-length string display in debug statement", " - minix: avoid overflow in bitmap block count calculation", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: convert READ_ONCE(*ptep) to ptep_get(ptep)", " - arm64/mm: convert set_pte_at() to set_ptes(..., 1)", " - arm64/mm: convert ptep_clear() to ptep_get_and_clear()", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - selftests/hid: convert the hid_bpf selftests with struct_ops", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - gue: validate REMCSUM private option length", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " - amt: fix size calculation in amt_get_size()", " - Bluetooth: 6lowpan: hold L2CAP conn across debugfs control", " - Bluetooth: MGMT: Fix adv monitor add failure cleanup", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - ring-buffer: Fix event length with forced 8-byte alignment", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: move functions to avoid forward definitions", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " - ipv6: mcast: Replace locking comments with lockdep annotations.", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " - s390/zcrypt: Remove the empty file", " - cifs: validate DFS referral string offsets", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " - dm era: fix NULL pointer dereference in metadata_open()", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " - selftests/net: fix EVP_MD_CTX leak in tcp_mmap", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - octeontx2-af: fix VF bringup affecting PF promiscuous state", " - smb: client: fix overflow in passthrough ioctl bounds check", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " - ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put", " - ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc", " - ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get", " - ASoC: SOF: topology: validate vendor array size before parsing", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " - net: atm: reject out-of-range traffic classes in QoS validation", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " - fbdev: vesafb: fix memory leak in vesafb_probe()", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " - ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get", " - ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Release reserved memory on cleanup", " - ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_cluster: reject template conntracks in hash match", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - netfilter: nf_nat_sip: reload possible stale data pointer", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " - netfilter: ecache: fix inverted time_after() check", " - netfilter: xt_nat: reject unsupported target families", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - selinux: check connect-related permissions on TCP Fast Open", " - leds: uleds: Fix potential buffer overread", " - mfd: sm501: Fix reference leak on failed device registration", " - tools/power/x86/intel-speed-select: Harden daemon pidfile open", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " - x86/boot: Reject too long acpi_rsdp= values", " - perf/x86/amd/lbr: Fix kernel address leakage", " - s390/perf_cpum_cf: Add missing array_index_nospec() to", " __hw_perf_event_init()", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: bla: reacquire gw address after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: tt: avoid request storms during pending request", " - batman-adv: fix VLAN priority offset", " - batman-adv: frag: free unfragmentable packet", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: tt: prevent TVLV OOB check overflow", " - cifs: invalidate cfid on unlink/rename/rmdir", " - mfd: tps6586x: Fix OF node refcount", " - HID: playstation: validate num_touch_reports in DualShock 4 reports", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " - nvdimm/btt: Free arenas on btt_init() error paths", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - mm/damon/core: make charge_addr_from aware of end-address exclusivity", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " - fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " - riscv: cacheinfo: Fix node reference leak in populate_cache_leaves", " - mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs()", " - mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error", " - proc: only bump parent nlink when registering directories", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - mtd: rawnand: pl353: fix probe resource allocation", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " - mtd: rawnand: fix condition in 'nand_select_target()'", " - ocfs2: avoid moving extents to occupied clusters", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " - ocfs2: add journal NULL check in ocfs2_checkpoint_inode()", " - ocfs2: reject dinodes with non-canonical i_mode type", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " - fpga: dfl: add bounds check in dfh_get_param_size()", " - bus: mhi: ep: Protect mhi_ep_handle_syserr() in the error path", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - fpga: microchip-spi: fix zero header_size OOB read in", " mpf_ops_parse_header()", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86/amd/pmc: Check for intermediate wakeup in function", " - platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops", " - platform/x86/amd/pmc: Add delay_suspend module parameter", " - smb: client: use kvzalloc() for megabyte buffer in simple fallocate", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - ice: fix ice_init_link() error return preventing probe", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - tpm: Make the TPM character devices non-seekable", " - time: Fix off-by-one in compat settimeofday() usec validation", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " - sctp: validate STALE_COOKIE cause length before reading staleness", " - nvmet-rdma: handle inline data with a nonzero offset", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " - can: bcm: add missing rcu list annotations and operations", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - net: sparx5: unregister blocking notifier on init failure", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " - dm era: fix out-of-bounds memory access for non-zero start sector", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-ioctl: fix a possible overflow in list_version_get_info", " - dm-log: fix a bitset_size overflow on 32bit machines", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm_early_create: fix freeing used table on dm_resume failure", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - scsi: sg: Report request-table problems when any status is set", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - validate control endpoint type", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - Input: ims-pcu - fix race condition in reset_device sysfs callback", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " - net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio-f7188x: Add support for NCT6126D version B", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: wwan: t7xx: destroy DMA pool on CLDMA late init failure", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - net: ena: clean up XDP TX queues when regular TX setup fails", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " - ieee802154: admin-gate legacy LLSEC dump operations", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " - batman-adv: ensure minimal ethernet header on TX", " - batman-adv: clean untagged VLAN on netdev registration failure", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - espintcp: use sk_msg_free_partial to fix partial send", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: mpfs: fix counter upload completion condition", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - net: liquidio: fix BAR resource leak on PF number failure", " - hwmon: (occ) unregister sysfs devices outside occ lock", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - net: lan743x: Initialize eth_syslock spinlock before use", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - net: wwan: iosm: bound device offsets in the MUX downlink decoder", " - hwmon: (asus_atk0110) Check package count before accessing element", " - riscv: probes: save original sp in rethook trampoline", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - drbd: reject data replies with an out-of-range payload size", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " - pmdomain: imx: Fix i.MX8MP power notifier", " - pmdomain: imx: Fix i.MX8MP VC8000E power up sequence", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - Bluetooth: btrtl: validate firmware patch bounds", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - memstick: ms_block: reject a card that reports too many blocks", " - ipvs: fix more places with wrong ipv6 transport offsets", " - ipvs: reload ip header after head reallocation", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: mac80211: free ack status frame on TX header build failure", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " - mtd: onenand: samsung: report DMA completion timeouts", " - mtd: mchp23k256: use SPI match data for chip caps", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " - perf/x86/amd/brs: Fix kernel address leakage", " - ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup", " - ACPI: bus: Introduce devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Use devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Fix possible deadlock and missing notifications", " - iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - iio: invensense: remove redundant initialization of variable period", " - iio: invensense: fix timestamp glitches when switching frequency", " - iio: imu: inv_icm42600: stabilized timestamp in interrupt", " - iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading", " - iio: pressure: mpl115: fix runtime PM leak on read error", " - bitops: make BYTES_TO_BITS() treewide-available", " - iio: common: st_sensors: honour channel endianness in read_axis_data", " - ALSA: aoa: check snd_ctl_new1() return value", " - PCI: altera: Fix resource leaks on probe failure", " - vfio/mlx5: Fix racy bitfields and tighten struct layout", " - PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling", " - PCI: controller: Use dev_fwnode() instead of of_fwnode_handle()", " - PCI: mediatek: Convert bool to single quirks entry and bitmap", " - PCI: mediatek: Use generic MACRO for TPVPERL delay", " - PCI: mediatek: Fix IRQ domain leak when port fails to enable", " - PCI: Prevent resource tree corruption when BAR resize fails", " - PCI: Free saved list without holding pci_bus_sem", " - PCI: Fix restoring BARs on BAR resize rollback path", " - PCI: Add kerneldoc for pci_resize_resource()", " - PCI: Move Resizable BAR code to rebar.c", " - PCI: Skip Resizable BAR restore on read error", " - staging: rtl8723bs: core: move constants to right side in comparison", " - staging: rtl8723bs: fix spaces around binary operators", " - staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),", " rtw_get_wapi_ie(), and rtw_get_wps_attr()", " - crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()", " - Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref", " - mm/shrinker: do not hold RCU lock in shrinker_debugfs_count_show()", " - coresight: etb10: restore atomic_t for shared reading state", " - gpio: sch: use raw_spinlock_t in the irq startup path", " - media: nxp: imx8-isi: Convert to platform remove callback returning void", " - media: nxp: imx8-isi: use devm_pm_runtime_enable() to simplify code", " - media: nxp: imx8-isi: Fix use-after-free on remove", " - netfilter: ebtables: Use vmalloc_array() to improve code", " - netfilter: ebtables: zero chainstack array", " - Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - smb: client: Improve unlocking of a mutex in cifs_get_swn_reg()", " - smb: client: resolve SWN tcon from live registrations", " - ksmbd: use opener credentials for FSCTL mutations", " - ksmbd: centralize ksmbd_conn final release to plug transport leak", " - ksmbd: track the connection owning a byte-range lock", " - proc: rename proc_setattr to proc_nochmod_setattr", " - proc: protect ptrace_may_access() with exec_update_lock (FD links)", " - writeback: fix race between cgroup_writeback_umount() and", " inode_switch_wbs()", " - perf/x86/intel/uncore: Defer ADL global PMON enable to enable_box()", " - HID: add haptics page defines", " - HID: multitouch: fix out-of-bounds bit access on mt_io_flags", " - mm/slab: do not limit zeroing to orig_size when only red zoning is", " enabled", " - seqlock: Introduce scoped_seqlock_read()", " - seqlock: Change do_task_stat() to use scoped_seqlock_read()", " - proc: protect ptrace_may_access() with exec_update_lock (part 1)", " - treewide: Switch/rename to timer_delete[_sync]()", " - HID: appleir: fix UAF on pending key_up_timer in remove()", " - serial: 8250_mid: Disable DMA for selected platforms", " - hfs/hfsplus: prevent getting negative values of offset/length", " - hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length", " - bpf: Consistently use bpf_rcu_lock_held() everywhere", " - bpf: Allow LPM map access from sleepable BPF programs", " - usb: iowarrior: remove inherent race with minor number", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - usb: typec: tcpm: Fix VDM type for Enter Mode commands", " - crypto: atmel - Drop explicit initialization of struct", " i2c_device_id::driver_data to 0", " - crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A", " - usb: gadget: f_fs: initialize reset_work at allocation time", " - nvmet: return DHCHAP status codes from nvmet_setup_auth()", " - nvmet-auth: validate reply message payload bounds against transfer", " length", " - usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile", " - btrfs: check and set EXTENT_DELALLOC_NEW before clearing EXTENT_DELALLOC", " - crypto: qat - fix restarting state leak on allocation failure", " - audit: add audit_log_nf_skb helper function", " - audit: fix potential integer overflow in audit_log_n_hex()", " - regulator: scmi: Simplify with scoped for each OF child loop", " - regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()", " - mm: do file ownership checks with the proper mount idmap", " - exfat: move free cluster out of exfat_init_ext_entry()", " - exfat: remove unnecessary read entry in __exfat_rename()", " - exfat: rename argument name for exfat_move_file and exfat_rename_file", " - exfat: add exfat_get_dentry_set_by_ei() helper", " - exfat: move exfat_chain_set() out of __exfat_resolve_path()", " - exfat: preserve benign secondary entries during rename and move", " - btrfs: fix false IO failure after falling back to buffered write", " - btrfs: fix incorrect buffered IO fallback for append direct writes", " - Bluetooth: hci_core: Enable buffer flow control for SCO/eSCO", " - Bluetooth: separate CIS_LINK and BIS_LINK link types", " - Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - seqlock: fix scoped_seqlock_read kernel-doc", " - Bluetooth: hci_core: Remove check of BDADDR_ANY in", " hci_conn_hash_lookup_big_state", " - Bluetooth: hci_sync: Fix attempting to send HCI_Disconnect to BIS handle", " - Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote", " netdev", " - selftests/hid: ensure CKI can compile our new tests on old kernels", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error harder", " - Bluetooth: btmtk: remove #ifdef around declarations", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - jiffies: Define secs_to_jiffies()", " - jiffies: Cast to unsigned long in secs_to_jiffies() conversion", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - tools/testing: add linux/args.h header and fix radix, VMA tests", " - selftests/bpf: Add simple strscpy() implementation", " - bcachefs: avoid truncating fiemap extent length", " - gpio: rockchip: change the GPIO version judgment logic", " - gpio: rockchip: teardown bugs and resource leaks", " - gpio: rockchip: fix generic IRQ chip leak on remove", " - NFSv4/flexfiles: Remove cred local variable dependency", " - iio: resolver: ad2s1210: notify trigger and clear state on fault read", " error", " - iio: temperature: Build mlx90635 with CONFIG_MLX90635", " - vfio: Remove device debugfs before releasing devres", " - PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000", " series", " - netpoll: fix a use-after-free on shutdown path", " - mm: shrinker: fix shrinker_info teardown race with expansion", " - NFSv4/flexfiles: Add data structure support for striped layouts", " - mm/khugepaged: write all dirty file folios when collapsing", " - platform/x86: intel-hid: Protect ACPI notify handler against recursion", " - Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled", " - Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()", " - fs/ntfs3: rename ni_readpage_cmpr into ni_read_folio_cmpr", " - ksmbd: use __GFP_RETRY_MAYFAIL", " - ksmbd: use opener credentials for ADS I/O", " - cpufreq: Make cpufreq_driver->exit() return void", " - cpufreq: qcom-cpufreq-hw: Fix possible double free", " - nvme: target: rdma: fix ndev refcount leak on queue connect", " - nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page", " - crypto: qat - keep VFs enabled during reset", " - crypto: qat - notify fatal error before AER reset preparation", " - crypto: qat - protect service table iterations with service_lock", " - selftests/mm: pagemap_ioctl: use the correct page size for", " transact_test()", " - iommufd: Set upper bounds on cache invalidation entry_num and entry_len", " - iommu/amd: Don't split flush for amd_iommu_domain_flush_all()", " - dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning", " - i2c: core: fix adapter probe deferral loop", " - xfs: fix null pointer dereference in tracepoint", " - xfs: don't wrap around quota ids in dqiterate", " - xfs: clamp timestamp nanoseconds correctly", " - xfs: don't zap bmbt forks if they are MAXLEVELS tall", " - iommu/vt-d: Clear Present bit before tearing down context entry", " - iommu: Pass old domain to set_dev_pasid op", " - iommu/vt-d: Cleanup intel_context_flush_present()", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " - vsock/virtio: bind uarg before filling zerocopy skb", " - iommu/amd: Use maximum Event log buffer size when SNP is enabled on", " Family 0x19", " - iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family", " 0x19", " - net: dropreason: Gather SOCKET_ drop reasons.", " - af_unix: Set drop reason in unix_release_sock().", " - af_unix: Set drop reason in manage_oob().", " - af_unix: Set drop reason in unix_stream_read_skb().", " - af_unix/scm: fix whitespace errors", " - af_unix: Don't hold unix_state_lock() in __unix_dgram_recvmsg().", " - af_unix: Don't check SOCK_DEAD in unix_stream_read_skb().", " - af_unix: Don't use skb_recv_datagram() in unix_stream_read_skb().", " - af_unix: Drop all SCM attributes for SOCKMAP.", " - time/jiffies: Change register_refined_jiffies() to void __init", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - media: uvcvideo: Do not add clock samples with small sof delta", " - serial: max310x: replace bare use of 'unsigned' with 'unsigned int'", " (checkpatch)", " - serial: max310x: implement gpio_chip::get_direction()", " - drm/gpuvm: Do not prepare NULL objects", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - soc: xilinx: Shutdown and free rx mailbox channel", " - crypto: qat - fix heartbeat error injection", " - memory: tegra: Wire up system sleep PM ops", " - drm/gpuvm: take refcount on DRM device", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - RDMA/hns: Initialize seqfile before creating file", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - RDMA/hns: Fix log flood after cmd_mbox failure", " - net: introduce page_frag_cache_drain()", " - nvmet-tcp: fix page fragment cache leak in error path", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - driver core: Use system_percpu_wq instead of system_wq", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - x86/cpu/amd: Provide a separate accessor for Node ID", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - netfilter: nfnetlink_cthelper: use {READ,WRITE}_ONCE for accessing", " helper flags", " - netfilter: synproxy: drop packets if timestamp adjustment fails", " - netfilter: synproxy: adjust duplicate timestamp options", " - netfilter: synproxy: fix unaligned memory access in timestamp adjustment", " - RDMA/siw: Fix endpoint/socket association handling", " - riscv: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - virtio_console: read size from config space during device init", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - net: dsa: qca8k: fix led devicename when using external mdio bus", " - ALSA: seq: Drop superfluous filter argument of get_event_dest_client()", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - dpll: add reference-sync netlink attribute", " - dpll: move xa_erase() call in to match dpll_pin_alloc() error path order", " - dpll: add reference sync get/set", " - dpll: Allow associating dpll pin with a firmware node", " - dpll: Add notifier chain for dpll events", " - dpll: Support dynamic pin index allocation", " - dpll: Enhance and consolidate reference counting logic", " - dpll: fix stale iteration in dpll_pin_on_pin_unregister()", " - dpll: send delete notification before unregister in on-pin rollback", " - dpll: emit per-dpll delete notifications in dpll_pin_on_pin_unregister()", " - dpll: guard sync-pair removal on full pin unregister", " - dpll: balance create/delete notifications in __dpll_pin_(un)register", " - landlock: Fix unmarked concurrent access to socket family", " - selftests/bpf: Fix typo in verify_umulti_link_info", " - udf: fix nls leak on udf_fill_super() failure", " - mfd: rsmu: Fix page register setup", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: split ep_insert() into alloc + register stages", " - eventpoll: extract ep_deliver_event() from ep_send_events()", " - eventpoll: wrap EP_UNACTIVE_PTR in typed sentinel helpers", " - eventpoll: rename epi->next and txlist for clarity", " - eventpoll: Fix epoll_wait() report false negative", " - gpiolib: acpi: Only trigger ActiveBoth interrupts on boot", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - PCI: meson: Add missing remove callback", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - workqueue: Add new WQ_PERCPU flag", " - i3c: master: add WQ_PERCPU to alloc_workqueue users", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - xfrm: Fix xfrm state cache insertion race", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - netfilter: ipset: make sure gc is properly stopped", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: hugetlb_reparenting_test: do not unmount", " - selftests/mm: save and restore nr_hugepages value", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - ipv6: annotate data-races around cnf.forwarding", " - ipv6/addrconf: annotate data-races around devconf fields (II)", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_info", " - ice: dpll: fix memory leak in ice_dpll_init_info error paths", " - net: bnxt: use ethtool string helpers", " - eth: bnxt: gather and report HW-GRO stats", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - ipv6: Add __in6_dev_get_rtnl_net().", " - octeontx2-af: Validate NIX maximum LFs correctly", " - udp_tunnel: remove rtnl_lock dependency", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - net: hisilicon: hns3: use ethtool string helpers", " - net: hns3: use string choices helper", " - net: hns3: use hns3_get_ae_dev() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: use hns3_get_ops() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: clear hns alarm: comparison of integer expressions of", " different signedness", " - net: hns3: unify copper port ksettings configuration path", " - net: hns3: refactor MAC autoneg and speed configuration", " - net: hns3: fix permanent link down deadlock after reset", " - net: hns3: differentiate autoneg default values between copper and fiber", " - rtnetlink: Add per-netns RTNL.", " - [Config] Set CONFIG_DEBUG_NET_SMALL_RTNL=n", " - rtnetlink: Add assertion helpers for per-netns RTNL.", " - rtnetlink: Define rtnl_net_trylock().", " - ipv6: Convert net.ipv6.conf.${DEV}.XXX sysctl to per-netns RTNL.", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Make /afs/. as well as /afs/ mountpoints", " - afs: Add rootcell checks", " - afs: Make /afs/@cell and /afs/.@cell symlinks", " - afs: Fix afs_atcell_get_link() to handle RCU pathwalk", " - afs: Remove the \"autocell\" mount option", " - afs: Change dynroot to create contents on demand", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - ovl: fix comment about locking order", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - afs: Convert comma to semicolon", " - afs: Fix double netfs initialisation in afs_root_iget()", " - drm/xe: Add warn when level can not be zero.", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - HID: bpf: Fix hid_bpf_get_data() range check", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - genirq/generic_chip: Introduce irq_domain_{alloc,remove}_generic_chips()", " - gpio: mvebu: free generic chips on unbind", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " - drm/xe: remove duplicate include", " - LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()", " - LoongArch: KVM: Check the return values for put_user()", " - LoongArch: KVM: Fix FPU register width with user access API", " - LoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr()", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - fbdev: efifb: fix memory leak in efifb_probe()", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - batman-adv: mcast: avoid OOB read of num_dests header", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()", " - fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry()", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - taskstats: retain dead thread stats in TGID queries", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - NFS: Charge unstable writes by request size, not folio size", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: make error counter atomic", " - accel/ivpu: Reject firmware log with size smaller than header", " - firmware_loader: introduce __free() cleanup hanler", " - Input: ims-pcu - fix firmware leak in async update", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - gpio: tegra: do not call pinctrl for GPIO direction", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - s390: Revert support for DCACHE_WORD_ACCESS", " - [Config] Set CONFIG_DCACHE_WORD_ACCESS=- for s390x", " - selftests: net: make busywait timeout clock portable", " - ata: libata: Use QUIRK instead of HORKAGE", " - ata: libata-core: Skip HPA resize for locked drives", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - ALSA: hda/cs35l41: Fix firmware load work teardown", " - io_uring/rw: ensure reissue path is correctly handled for IOPOLL", " - io_uring/rw: preserve partial result for iopoll", " - Bluetooth: L2CAP: Fix not tracking outstanding TX ident", " - mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless", " host", " - ksmbd_vfs_rename(): vfs_path_parent_lookup() accepts ERR_PTR() as name", " - vfs: make LAST_XXX private to fs/namei.c", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " - HID: pidff: Fix missing blank lines after declarations", " - HID: pidff: Add missing spaces", " - HID: pidff: Rework pidff_upload_effect", " - HID: pidff: Use correct effect type in effect update", " - bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()", " - USB: iowarrior: fix use-after-free on disconnect race", " - crypto: atmel-sha204a - fail on hwrng registration error in probe path", " - btrfs: concentrate the error handling of submit_one_sector()", " - btrfs: remove folio parameter from ordered io related functions", " - btrfs: remove the COW fixup mechanism", " - slab: Introduce kmalloc_obj() and family", " - slab: Introduce kmalloc_flex() and family", " - add default_gfp() helper macro and use it in the new *alloc_obj()", " helpers", " - default_gfp(): avoid using the \"newfangled\" __VA_OPT__ trick", " - slab: recognize @GFP parameter as optional in kernel-doc", " - fscrypt: Fix key setup in edge case with multiple data unit sizes", " - fscrypt: Replace mk_users keyring with simple list", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is", " uninitialized", " - rtnetlink: Make per-netns RTNL dereference helpers to macro.", " - afs: Fix afs_atcell_get_link() to check if ws_cell is unset first", " - afs: Fix afs_dynroot_readdir() to not use the RCU read lock", " - udp_tunnel: fix deadlock in udp_tunnel_nic_set_port_priv()", " - i40e: drop udp_tunnel_get_rx_info() call from i40e_open()", " - ice: drop udp_tunnel_get_rx_info() call from ndo_open()", " - Bluetooth: L2CAP: Fix regressions caused by reusing ident", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " - perf: Reject exited events as group leaders", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - proc: Fix broken error paths for namespace links", " - Upstream stable to v6.6.145, v6.12.96, v6.12.97", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2026-53365", " - vsock/virtio: fix zerocopy completion for multi-skb sends", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two", " - x86/mm: Fix check/use ordering in switch_mm_irqs_off()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192)", " - debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING", " - debugobjects: Use LD_WAIT_CONFIG instead of LD_WAIT_SLEEP", " - debugobjects: Dont call fill_pool() in early boot hardirq context", " - ARM: group is_permission_fault() with is_translation_fault()", " - ARM: allow __do_kernel_fault() to report execution of memory faults", " - ARM: fix branch predictor hardening", " - RDMA/bnxt_re: zero shared page before exposing to userspace", " - selftests/bpf: Add test to ensure kprobe_multi is not sleepable", " - bpf: Remove mark_precise_scalar_ids()", " - selftests/bpf: Tests for per-insn sync_linked_regs() precision tracking", " - selftests/bpf: Update comments find_equal_scalars->sync_linked_regs", " - hv: utils: handle and propagate errors in kvp_register", " - Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs", " - phonet: Pass ifindex to fill_addr().", " - phonet: Pass net and ifindex to phonet_address_notify().", " - scripts/sorttable: Remove unused macro defines", " - scripts/sorttable: Remove unused write functions", " - scripts/sorttable: Remove unneeded Elf_Rel", " - scripts/sorttable: Have the ORC code use the _r() functions to read", " - scripts/sorttable: Make compare_extable() into two functions", " - scripts/sorttable: Convert Elf_Ehdr to union", " - scripts/sorttable: Replace Elf_Shdr Macro with a union", " - scripts/sorttable: Convert Elf_Sym MACRO over to a union", " - scripts/sorttable: Add helper functions for Elf_Ehdr", " - scripts/sorttable: Add helper functions for Elf_Shdr", " - scripts/sorttable: Add helper functions for Elf_Sym", " - scripts/sorttable: Use uint64_t for mcount sorting", " - scripts/sorttable: Move code from sorttable.h into sorttable.c", " - scripts/sorttable: Get start/stop_mcount_loc from ELF file directly", " - scripts/sorttable: Use a structure of function pointers for elf helpers", " - arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64", " - [Config] Set configs to sort mcount_loc at boot for arm64", " - scripts/sorttable: Have mcount rela sort use direct values", " - scripts/sorttable: Always use an array for the mcount_loc sorting", " - scripts/sorttable: Zero out weak functions in mcount_loc table", " - ftrace: Update the mcount_loc check of skipped entries", " - ftrace: Have ftrace pages output reflect freed pages", " - ftrace: Do not over-allocate ftrace memory", " - ftrace: Test mcount_loc addr before calling ftrace_call_addr()", " - ftrace: Check against is_kernel_text() instead of kaslr_offset()", " - scripts/sorttable: Use normal sort if theres no relocs in the mcount", " section", " - scripts/sorttable: Allow matches to functions before function entry", " - scripts/sorttable: Fix endianness handling in build-time mcount sort", " - file: add fput() cleanup helper", " - eventpoll: use hlist_is_singular_node() in __ep_remove()", " - Revert \"ptp: add testptp mask test\"", " - Bluetooth: btmtk: validate WMT event SKB length before struct access", " - Bluetooth: btmtk: accept too short WMT FUNC_CTRL events", " - batman-adv: tp_meter: keep unacked list in ascending ordered", " - batman-adv: tp_meter: initialize dup_acks explicitly", " - batman-adv: tp_meter: initialize dec_cwnd explicitly", " - batman-adv: tp_meter: avoid window underflow", " - batman-adv: tp_meter: fix fast recovery precondition", " - batman-adv: tp_meter: handle seqno wrap-around for fast recovery", " detection", " - batman-adv: tp_meter: add only finished tp_vars to lists", " - batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE", " - batman-adv: prevent ELP transmission interval underflow", " - batman-adv: tp_meter: initialize last_recv_time during init", " - batman-adv: ensure bcast is writable before modifying TTL", " - batman-adv: fix (m|b)cast csum after decrementing TTL", " - batman-adv: frag: ensure fragment is writable before modifying TTL", " - batman-adv: frag: avoid underflow of TTL", " - batman-adv: tp_meter: annotate last_recv_time access with", " READ/WRITE_ONCE", " - batman-adv: tp_meter: prevent parallel modifications of last_recv", " - batman-adv: tp_meter: handle overlapping packets", " - batman-adv: tt: don't merge change entries with different VIDs", " - batman-adv: tt: track roam count per VID", " - batman-adv: dat: prevent false sharing between VLANs", " - batman-adv: tvlv: enforce 2-byte alignment", " - batman-adv: tvlv: avoid race of cifsnotfound handler state", " - inet: add indirect call wrapper for getfrag() calls", " - err.h: use __always_inline on all error pointer helpers", " - wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S", " - wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor", " - wifi: rtw88: increase TX report timeout to fix race condition", " - wifi: iwlwifi: mvm: fix race condition in PTP removal", " - f2fs: fix to round down start offset of fallocate for pin file", " - f2fs: keep atomic write retry from zeroing original data", " - MIPS: DEC: Prevent initial console buffer from landing in XKPHYS", " - fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode", " - nfsd: check get_user() return when reading princhashlen", " - NFS: Prevent resource leak in nfs_alloc_server()", " - serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero", " - wifi: mt76: mt7921: avoid undesired changes of the preset regulatory", " domain", " - ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()", " - xfs: fix error returns in CoW fork repair", " - locking/mutex: Remove wakeups from under mutex::wait_lock", " - net: ipv6: Make udp_tunnel6_xmit_skb() void", " - Revert \"PCI: qcom: Advertise Hotplug Slot Capability with no Command", " Completion support\"", " - KVM: SEV: Ignore MMIO requests of length '0'", " - mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program", " - mtd: spi-nor: macronix: add support for mx66{l2, u1}g45g", " - LoongArch: Report dying CPU to RCU in stop_this_cpu()", " - MIPS: smp: report dying CPU to RCU in stop_this_cpu()", " - locking: rtmutex: Fix wake_q logic in task_blocks_on_rt_mutex", " - bonding: annotate data-races arcound churn variables", " - Upstream stable to v6.6.144, v6.12.95", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53389", " - net/tcp-ao: fix use-after-free of key in del_async path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53393", " - nfsd: reset write verifier on deferred writeback errors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53400", " - i2c: core: fix adapter registration race", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63806", " - KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with", " get_unaligned()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63940", " - KVM: SEV: Ignore Port I/O requests of length '0'", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53387", " - iio: light: veml6075: add bounds check to veml6075_it_ms index", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53070", " - sctp: disable BH before calling udp_tunnel_xmit_skb()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43216", " - net: Drop the lock in skb_may_tx_timestamp()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64244", " - drivers/base/memory: set mem->altmap after successful device", " registration", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53384", " - serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53390", " - ksmbd: fix out-of-bounds read in smb_check_perm_dacl()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53391", " - NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53397", " - nfsd: fix posix_acl leak on SETACL decode failure", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64245", " - fbdev: modedb: fix a possible UAF in fb_find_mode()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53403", " - fbdev: Fix fb_new_modelist to prevent null-ptr-deref in", " fb_videomode_to_var", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64246", " - power: reset: linkstation-poweroff: fix use-after-free in the", " linkstation_poweroff_init()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63794", " - KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64247", " - KVM: x86: hyper-v: Bound the bank index when querying sparse banks", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63795", " - 9p: avoid putting oldfid in p9_client_walk() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63796", " - ocfs2: reject oversized group bitmap descriptors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63797", " - rpmsg: char: Fix use-after-free on probe error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64249", " - fpga: region: fix use-after-free in child_regions_with_firmware()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63798", " - irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup", " on remove", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63801", " - tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63802", " - blk-cgroup: fix UAF in __blkcg_rstat_flush()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63803", " - hdlc_ppp: sync per-proto timers before freeing hdlc state", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63804", " - gfs2: fix use-after-free in gfs2_qd_dealloc", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63809", " - bpf: use kvfree() for replaced sysctl write buffer", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63812", " - f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63814", " - f2fs: validate ACL entry sizes in f2fs_acl_from_disk()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63817", " - f2fs: validate compress cache inode only when enabled", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63821", " - wifi: rtw88: usb: fix memory leaks on USB write failures", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63822", " - wifi: ath11k: fix warning when unbinding", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63823", " - keys: Pin request_key_auth payload in instantiate paths", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63824", " - KEYS: fix overflow in keyctl_pkey_params_get_2()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63826", " - fbdev: fix use-after-free in store_modes()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64254", " - NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG", " share BAR", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63827", " - apparmor: fix use-after-free in rawdata dedup loop", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63828", " - apparmor: mediate the implicit connect of TCP fast open sendmsg", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63830", " - net: skmsg: preserve sg.copy across SG transforms", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63831", " - mac802154: llsec: add skb_cow_data() before in-place crypto", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53361", " - af_unix: Set gc_in_progress to true in unix_gc().", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63833", " - ntfs3: reject direct userspace writes to reserved $LX* xattrs", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53366", " - ipv4: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53362", " - ipv6: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63834", " - batman-adv: tp_meter: restrict number of unacked list entries", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63835", " - batman-adv: v: prevent OGM aggregation on disabled hardif", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63836", " - batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63807", " - KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping", " level", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53381", " - virtiofs: fix UAF on submount umount", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53382", " - media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53383", " - ksmbd: reject non-VALID session in compound request branch", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53385", " - vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent", " vcs_write", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53388", " - fuse: re-lock request before replacing page cache folio", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53157", " - net: phonet: free phonet_device after RCU grace period", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53163", " - locking/rtmutex: Skip remove_waiter() when waiter is not enqueued", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2025-23131", " - dlm: prevent NPD when writing a positive value to event_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-46252", " - regulator: core: fix locking in regulator_resolve_supply() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52928", " - af_unix: Reject SIOCATMARK on non-stream sockets", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43010", " - bpf: Reject sleepable kprobe_multi programs at attach time", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53325", " - agp/amd64: Fix broken error propagation in agp_amd64_probe()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64188", " - net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64191", " - i2c: stub: Reject I2C block transfers with invalid length", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53327", " - debugobjects: Do not fill_pool() if pi_blocked_on", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52909", " - ip6_vti: set netns_immutable on the fallback device.", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53167", " - fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios", "" ], "package": "linux", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 11:03:24 +0200" }, { "cves": [ { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-146.146 -proposed tracker (LP: #2166353)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", "", " * Bluetooth fails to initialize due to a kernel NULL pointer error", " (LP: #2165873)", " - Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c", "", " * Dell Precision fails to shutdown when HDMI display is connected (22.04", " HWE) (LP: #2164507)", " - drm/i915/vbt: Add fields dedicated_external and dyn_port_over_tc", " - drm/i915/display: Handle dedicated external ports in", " intel_encoder_is_tc()", "", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", "", " * [SRU] HPE: Fix for UBSAN array-index-out-of-bounds (LP: #2161004)", " - x86/platform/uv: Fix UBSAN array-index-out-of-bounds", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough", " (LP: #2089306)", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Reboot machine with ext4 configured to data=journal could dump spurious", " call trace (LP: #2164716)", " - ext4: clear stale xarray tags on folios skipped during writeback", "", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", "", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796)", " - netfilter: bitwise: rename some boolean operation functions", " - netfilter: bitwise: add support for doing AND, OR and XOR directly", " - drm/fbdev-helper: Set and clear VGA switcheroo client from fb_info", " - arm64: io: Rename ioremap_prot() to __ioremap_prot()", " - Disable -Wattribute-alias for clang-23 and newer", " - netfilter: xt_NFQUEUE: prefer raw_smp_processor_id", " - drm/imx: Fix three kernel-doc warnings in dcss-scaler.c", " - pcnet32: stop holding device spin lock during napi_complete_done", " - net: Annotate sk->sk_write_space() for UDP SOCKMAP.", " - net: lan743x: permit VLAN-tagged packets up to configured MTU", " - net: fec: fix pinctrl default state restore order on resume", " - Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame()", " extension handling", " - Bluetooth: MGMT: Fix backward compatibility with userspace", " - ptp: vclock: Switch from RCU to SRCU", " - octeontx2-af: npc: Fix CPT channel mask in npc_install_flow", " - vxlan: vnifilter: send notification on VNI add", " - vxlan: vnifilter: fix spurious notification on VNI update", " - ipmi: Fix rcu_read_unlock to srcu_read_unlock in handle_read_event_rsp", " - time: Fix off-by-one in settimeofday() usec validation", " - tools/rv: Fix cleanup after failed trace setup", " - arm64: tlb: Allow XZR argument to TLBI ops", " - iomap: don't revert iov_iter on partially completed buffered writes", " - net/mlx4: avoid GCC 10 __bad_copy_from() false positive", " - r8152: handle the return value of usb_reset_device()", " - rds: mark snapshot pages dirty in rds_info_getsockopt()", " - net: mvpp2: Add metadata support for xdp mode", " - net: mvpp2: build skb from XDP-adjusted data on XDP_PASS", " - clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time", " - tracing/probes: Point the error offset correctly for eprobe argument", " error", " - mmc: litex_mmc: Use DIV_ROUND_UP for more accurate clock calculation", " - USB: serial: option: add usb-id for Dell Wireless DW5826e-m", " - ALSA: timer: Fix UAF at snd_timer_user_params()", " - drm/amd/display: Reject gpio_bitshift >= 32 in", " bios_parser_get_gpio_pin_info()", " - mm/damon/ops-common: call folio_test_lru() after folio_get()", " - ARM: socfpga: Fix OF node refcount leak in SMP setup", " - ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O", " - mptcp: fix retransmission loop when csum is enabled", " - mptcp: sockopt: check timestamping ret value", " - selftests: mptcp: add test for extra_subflows underflow on userspace PM", " - ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write", " - inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush", " - pidfd: refuse access to tasks that have started exiting harder", " - i2c: stm32f7: fix timing computation ignoring i2c-analog-filter", " - i2c: tegra: Fix NOIRQ suspend/resume", " - Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)", " - Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard", " - net/mlx5: Reorder completion before putting command entry in", " cmd_work_handler", " - net: mv643xx: fix OF node refcount", " - octeontx2-af: fix memory leak in rvu_setup_hw_resources()", " - mmc: core: Fix host controller programming for fixed driver type", " - mmc: litex_mmc: Set mandatory idle clocks before CMD0", " - mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC", " - mmc: sdhci: add signal voltage switch in sdhci_resume_host", " - slimbus: qcom-ngd-ctrl: fix OF node refcount", " - drm/amdgpu: restart the CS if some parts of the VM are still invalidated", " - fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling", " - driver core: reject devices with unregistered buses", " - mm/hugetlb: avoid false positive lockdep assertion", " - soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get()", " - ipmi:ssif: Remove unnecessary indention", " - ipmi:ssif: NULL thread on error", " - selftests: mptcp: drop nanoseconds width specifier", " - tty: serial: samsung: use u32 for register interactions", " - RDMA/umem: fix kernel-doc warnings", " - RDMA: Move DMA block iterator logic into dedicated files", " - arm64: cputype: Add NVIDIA Olympus definitions", " - arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU", " - mptcp: add-addr: always drop other suboptions", " - mptcp: fix missing wakeups in edge scenarios", " - Revert \"selftest/ptp: update ptp selftest to exercise the gettimex", " options\"", " - ARM: fix hash_name() fault", " - wifi: remove zero-length arrays", " - soc: qcom: ice: Return -ENODEV if the ICE platform device is not found", " - Bluetooth: ISO: Fix not using bc_sid as advertisement SID", " - octeontx2-pf: Fix NDC sync operation errors", " - octeontx2-af: Fix initialization of mcam's entry2target_pffunc field", " - ima: kexec: skip IMA segment validation after kexec soft reboot", " - ima: kexec: move IMA log copy from kexec load to execute", " - gpio: zynq: fix runtime PM leak on remove", " - writeback: Avoid contention on wb->list_lock when switching inodes", " - writeback: Fix use after free in inode_switch_wbs_work_fn()", " - xfrm: hold device only for the asynchronous decryption", " - KVM: VMX: Update SVI during runtime APICv activation", " - drm/xe: fix refcount leak in xe_range_fence_insert()", " - slimbus: qcom-ngd-ctrl: Fix up platform_driver registration", " - slimbus: qcom-ngd-ctrl: Fix probe error path ordering", " - slimbus: qcom-ngd-ctrl: Initialize controller resources in controller", " - slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership", " - slimbus: qcom-ngd-ctrl: Balance pm_runtime enablement for NGD", " - drm/amd/pm: fix smu13 power limit default/cap calculation", " - drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in", " set_soft_freq_limited_range", " - drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs", " - mailbox: Fix NULL message support in mbox_send_message()", " - vsock/virtio: fix skb overhead accounting to preserve full buf_alloc", " - net: introduce EXPORT_IPV6_MOD() and EXPORT_IPV6_MOD_GPL()", " - mptcp: pm: fix extra_subflows underflow on userspace PM subflow creation", " - vsock/virtio: fix skb overhead overflow on 32-bit builds", " - Upstream stable to v6.6.143, v6.12.94", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53132", " - vsock/virtio: fix potential unbounded skb queue", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53138", " - drm/amd/display: Bound VBIOS record-chain walk loops", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53140", " - drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53332", " - slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53156", " - nvmem: core: fix use-after-free bugs in error paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53202", " - accel/ivpu: Fix signed integer truncation in IPC receive", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53205", " - accel/ivpu: Add bounds checks for firmware log indices", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53210", " - tee: shm: fix shm leak in register_shm_helper()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-31663", " - xfrm: hold dev ref until after transport_finish NF_HOOK", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53220", " - netfilter: revalidate bridge ports", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53229", " - net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46203", " - spi: cadence-quadspi: fix unclocked access on unbind", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63871", " - Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53251", " - Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63869", " - wifi: mac80211: limit injected antenna index in", " ieee80211_parse_tx_radiotap", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53261", " - devlink: Release nested relation on devlink free", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53262", " - l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses", " - arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-45850", " - ipvs: skip ipv6 extension headers for csum checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53133", " - RDMA/umem: Fix truncation for block sizes >= 4G", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52908", " - RDMA: During rereg_mr ensure that REREG_ACCESS is compatible", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53199", " - hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53134", " - netfilter: nft_fib: fix stale stack leak via the OIFNAME register", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63883", " - serial: qcom_geni: fix kfifo underflow when flush precedes DMA", " completion IRQ", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64528", " - tty: serial: samsung: Remove redundant port lock acquisition in rx", " helpers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53329", " - drm/amd/display: Use krealloc_array() in dal_vector_reserve()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53135", " - drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53136", " - drm/amd/display: Clamp VBIOS HDMI retimer register count to array size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53137", " - drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53143", " - drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on", " GFX11", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53144", " - drm/amdkfd: fix NULL dereference in get_queue_ids()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53331", " - slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53146", " - thunderbolt: Limit XDomain response copy to actual frame size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53147", " - thunderbolt: Validate XDomain request packet size before type cast", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53148", " - thunderbolt: Clamp XDomain response data copy to allocation size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53149", " - thunderbolt: Bound root directory content to block size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53150", " - thunderbolt: Reject zero-length property entries in validator", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52929", " - sctp: stream: fully roll back denied add-stream state", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52917", " - sctp: diag: reject stale associations in dump_one path", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53154", " - mm/hugetlb: restore reservation on error in hugetlb folio copy paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53336", " - nvmem: layouts: onie-tlv: fix hang on unknown types", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53337", " - net: bonding: fix NULL pointer dereference in bond_do_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53158", " - misc: fastrpc: Fix NULL pointer dereference in rpmsg callback", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53159", " - misc: fastrpc: fix DMA address corruption due to find_vma misuse", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53160", " - misc: fastrpc: fix use-after-free race in fastrpc_map_create", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53161", " - misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52930", " - ipc/shm: serialize orphan cleanup with shm_nattch updates", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53339", " - i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53168", " - fuse: reject fuse_notify() pagecache ops on directories", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53177", " - bnxt_en: Fix NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53181", " - vsock/vmci: fix sk_ack_backlog leak on failed handshake", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53182", " - wifi: nl80211: reject oversized EMA RNR lists", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53183", " - mptcp: allow subflow rcv wnd to shrink", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63867", " - mptcp: close TOCTOU race while computing rcv_wnd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53343", " - ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53184", " - udp: clear skb->dev before running a sockmap verdict", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53185", " - zram: fix use-after-free in zram_bvec_write_partial()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53190", " - drm/virtio: fix dma_fence refcount leak on error in", " virtio_gpu_dma_fence_wait()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53194", " - USB: serial: kl5kusb105: fix bulk-out buffer overflow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53195", " - USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53196", " - USB: serial: io_ti: fix heap overflow in get_manuf_info()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52935", " - xfrm: espintcp: do not reuse an in-progress partial send", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53198", " - ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53356", " - drm/i915/gem: Fix phys BO pread/pwrite with offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53345", " - KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53208", " - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53209", " - Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53213", " - drm/vc4: fix krealloc() memory leak", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53347", " - drm/virtio: Fix driver removal with disabled KMS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43116", " - netfilter: ctnetlink: ensure safe access to master conntrack", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53214", " - ipv6: Fix a potential NPD in cleanup_prefix_route()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53217", " - net: mvpp2: sync RX data at the hardware packet offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53218", " - netfilter: nft_exthdr: fix register tracking for F_PRESENT flag", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52942", " - netfilter: nf_log: validate MAC header was set before dumping it", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53219", " - netfilter: x_tables: avoid leaking percpu counter pointers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53349", " - netfilter: nf_conntrack: destroy stale expectfn expectations on", " unregister", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52939", " - net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic", " completion", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53223", " - net: guard timestamp cmsgs to real error queue skbs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53227", " - net: openvswitch: fix possible kfree_skb of ERR_PTR", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53230", " - net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52947", " - net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53232", " - net: phy: clean the sfp upstream if phy probing fails", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53236", " - tcp: restrict SO_ATTACH_FILTER to priv users", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53350", " - ASoC: wm_adsp: Fix NULL dereference when removing firmware controls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53237", " - gpio: mvebu: fix NULL pointer dereference in suspend/resume", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53238", " - netlabel: validate unlabeled address and mask attribute lengths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53239", " - xfrm: policy: fix use-after-free on inexact bin in", " xfrm_policy_bysel_ctx()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46320", " - tap: free page on error paths in tap_get_user_xdp()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53242", " - ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked", " streams", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53352", " - signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53245", " - net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63870", " - ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53249", " - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53252", " - Bluetooth: fix memory leak in error path of hci_alloc_dev()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53253", " - Bluetooth: bnep: reject short frames before parsing", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53254", " - Bluetooth: RFCOMM: validate skb length in MCC handlers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53255", " - Bluetooth: MGMT: validate advertising TLV before type checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53256", " - Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63868", " - net: garp: fix unsigned integer underflow in garp_pdu_parse_attr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53353", " - hsr: Remove WARN_ONCE() in hsr_addr_is_self().", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53263", " - 6lowpan: fix off-by-one in multicast context address compression", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53264", " - net/sched: act_api: use RCU with deferred freeing for action lifecycle", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53265", " - dm cache policy smq: check allocation under invalidate lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53266", " - netfilter: bridge: make ebt_snat ARP rewrite writable", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53267", " - netfilter: nft_ct: bail out on template ct in get eval", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53268", " - netfilter: conntrack_irc: fix possible out-of-bounds read", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53269", " - netfilter: synproxy: add mutex to guard hook reference counting", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53270", " - ipvs: clear the svc scheduler ptr early on edit", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53273", " - tee: optee: prevent use-after-free when the client exits before the", " supplicant", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53274", " - net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53275", " - ipv6: mcast: Fix use-after-free when processing MLD queries", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52948", " - i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63898", " - USB: serial: mct_u232: fix memory corruption with small endpoint", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52910", " - bpf: Free reuseport cBPF prog after RCU grace period.", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43311", " - soc/tegra: pmc: Fix unsafe generic_handle_irq() call", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43240", " - x86/kexec: add a sanity check on previous kernel's ima kexec buffer", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-23346", " - arm64: io: Extract user memory type in ioremap_prot()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52944", " - ksmbd: fix FSCTL permission bypass by adding a permission check for", " FSCTL_SET_SPARSE", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64006", " - netfilter: nf_tables: fix dst corruption in same register operation", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547)", " - Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size", " - drm/v3d: Fix use-after-free of CPU job query arrays on error path", " - drm/v3d: Release indirect CSD GEM reference on CPU job free", " - xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit", " - net/sched: sch_sfb: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - bcache: fix uninitialized closure object", " - nfc: llcp: Fix use-after-free in llcp_sock_release()", " - nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()", " - xfrm: Check for underflow in xfrm_state_mtu", " - nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems", " - kunit: fix use-after-free in debugfs when using kunit.filter", " - netfilter: xt_cpu: prefer raw_smp_processor_id", " - vsock: keep poll shutdown state consistent", " - net: netlink: fix sending unassigned nsid after assigned one", " - net: netlink: don't set nsid on local notifications", " - net/smc: Do not re-initialize smc hashtables", " - net/iucv: fix locking in .getsockopt", " - scsi: core: Run queues for all non-SDEV_DEL devices from", " scsi_run_host_queues", " - ipv4: free net->ipv4.sysctl_local_reserved_ports after", " unregister_net_sysctl_table()", " - ALSA: pcm: oss: Fix setup list UAF on proc write error", " - ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors", " - gpio: mxc: fix irq_high handling", " - ethtool: rss: fix hkey leak when indir_size is 0", " - ASoC: codecs: simple-mux: Fix enum control bounds check", " - Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()", " - bonding: refuse to enslave CAN devices", " - ethtool: eeprom: add missing ethnl_ops_begin() / _complete() during", " fallback", " - ethtool: eeprom: add more safeties to EEPROM Netlink fallback", " - net/sched: Revert \"net/sched: Restrict conditions for adding duplicating", " netems to qdisc tree\"", " - net/handshake: Use spin_lock_bh for hn_lock", " - nvme-tcp: store negative errno in queue->tls_err", " - net/handshake: Pass negative errno through handshake_complete()", " - Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success", " - Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp", " - Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close", " - gpio: rockchip: convert bank->clk to devm_clk_get_enabled()", " - net: mana: Add NULL guards in teardown path to prevent panic on attach", " failure", " - sctp: fix race between sctp_wait_for_connect and peeloff", " - ipv6: fix possible infinite loop in rt6_fill_node()", " - ipv6: fix possible infinite loop in fib6_select_path()", " - net: skbuff: fix pskb_carve leaking zcopy pages", " - perf: Fix dangling cgroup pointer in cpuctx", " - batman-adv: tvlv: abort OGM send on tvlv append failure", " - batman-adv: tt: reject oversized local TVLV buffers", " - batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface", " - batman-adv: iv: recover OGM scheduling after forward packet error", " - batman-adv: tp_meter: avoid role confusion in tp_list", " - batman-adv: tp_meter: directly shut down timer on cleanup", " - batman-adv: tt: avoid empty VLAN responses", " - batman-adv: bla: avoid double decrement of bla.num_requests", " - media: rc: fix race between unregister and urb/irq callbacks", " - media: rc: ttusbir: fix inverted error logic", " - inet: frags: add inet_frag_queue_flush()", " - HID: core: Add printk_ratelimited variants to hid_warn() etc", " - drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register", " - drm/i915/psr: Read Intel DPCD workaround register", " - drm/dp: Add eDP 1.5 bit definition", " - drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used", " - phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X", " - batman-adv: tt: prevent TVLV entry number overflow", " - iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer", " - usb: typec: ucsi: ccg: reject firmware images without a ':' record", " header", " - usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload", " VDO", " - usb: typec: altmodes/displayport: validate count before reading Status", " Update VDO", " - usb: typec: wcove: don't write past struct pd_message in", " wcove_read_rx_buffer()", " - usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT", " - usb: typec: ucsi: validate connector number in ucsi_connector_change()", " - USB: serial: safe_serial: fix memory corruption with small endpoint", " - media: rc: igorplugusb: fix control request setup packet", " - Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free()", " - HID: quirks: Add ALWAYS_POLL quirk for SIGMACHIP USB mouse", " - Bluetooth: btusb: Allow firmware re-download when version matches", " - hpfs: fix a crash if hpfs_map_dnode_bitmap fails", " - auxdisplay: line-display: fix OOB read on zero-length message_store()", " - Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn", " - Bluetooth: HIDP: fix missing length checks in hidp_input_report()", " - Bluetooth: ISO: fix UAF in iso_recv_frame", " - Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock", " - Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync", " - Input: xpad - fix out-of-bounds access for Share button", " - parport: Fix race between port and client registration", " - USB: cdc-acm: Fix bit overlap and move quirk definitions to header", " - KVM: arm64: PMU: Preserve AArch32 counter low bits", " - KVM: SVM: Flush the current TLB when transitioning from xAVIC => x2AVIC", " - iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux", " - iio: adc: npcm: fix unbalanced clk_disable_unprepare()", " - iio: dac: max5821: fix return value check in powerdown sync", " - iio: dac: ad5686: fix input raw value check", " - iio: dac: ad5686: acquire lock when doing powerdown control", " - iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw", " - iio: gyro: itg3200: fix i2c read into the wrong stack location", " - iio: gyro: adis16260: fix division by zero in write_raw", " - iio: ssp_sensors: cancel delayed work_refresh on remove", " - iio: temperature: tsys01: fix broken PROM checksum validation", " - iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL", " - iio: light: cm3323: fix reg_conf not being initialized correctly", " - iio: buffer: hw-consumer: fix use-after-free in error path", " - USB: serial: omninet: fix memory corruption with small endpoint", " - usb: cdns3: gadget: fix request skipping after clearing halt", " - usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy", " acquisition failure", " - usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently", " leaks the runtime PM usage counter across bind/unbind cycles", " - usb: dwc2: Fix use after free in debug code", " - Input: elan_i2c - validate firmware size before use", " - wireguard: send: append trailer after expanding head", " - bpf: sockmap: fix tail fragment offset in bpf_msg_push_data", " - macsec: fix replay protection at XPN lower-PN wrap", " - ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params", " - ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().", " - ipv6: validate extension header length before copying to cmsg", " - xfrm: input: hold netns during deferred transport reinjection", " - ip6: vti: Use ip6_tnl.net in vti6_changelink().", " - HID: wacom: Fix OOB write in wacom_hid_set_device_mode()", " - iommu, debugobjects: avoid gcc-16.1 section mismatch warnings", " - nfc: hci: fix out-of-bounds read in HCP header parsing", " - xfrm: route MIGRATE notifications to caller's netns", " - xfrm: ah: use skb_to_full_sk in async output callbacks", " - ALSA: scarlett2: Fix 2i2 Gen 4 direct monitor gain on firmware 2417", " - netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without", " direction check", " - ASoC: qcom: q6asm-dai: close stream only when running", " - ASoC: qcom: q6asm-dai: do not set stream state in event and trigger", " callbacks", " - Input: xpad - add \"Nova 2 Lite\" from GameSir", " - Input: xpad - add support for ASUS ROG RAIKIRI II", " - ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops", " - Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem", " - Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490", " - comedi: comedi_test: fix check for valid scan_begin_src in", " waveform_ai_cmdtest()", " - comedi: comedi_test: Fix limiting of convert_arg in", " waveform_ai_cmdtest()", " - counter: Fix refcount leak in counter_alloc() error path", " - tty: serial: pch_uart: add check for dma_alloc_coherent()", " - usb: chipidea: core: convert ci_role_switch to local variable", " - usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval", " - USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub", " controllers", " - usb: storage: Add quirks for PNY Elite Portable SSD", " - usbip: vudc: Fix use after free bug in vudc_remove due to race condition", " - usb: usbtmc: check URB actual_length for interrupt-IN notifications", " - usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize", " - USB: serial: option: add MeiG SRM813Q", " - USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL", " - USB: serial: belkin_sa: validate interrupt status length", " - USB: serial: cypress_m8: validate interrupt packet headers", " - USB: serial: keyspan: fix missing indat transfer sanity check", " - USB: serial: mxuport: fix memory corruption with small endpoint", " - USB: serial: mct_u232: fix missing interrupt-in transfer sanity check", " - usb: gadget: uvc: hold opts->lock across XU walks in uvc_function_bind", " - usb: gadget: net2280: Fix double free in probe error path", " - usb: gadget: f_hid: fix device reference leak in hidg_alloc()", " - usb: gadget: composite: fix integer underflow in WebUSB GET_URL handling", " - usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports", " - usb: gadget: f_fs: copy only received bytes on short ep0 read", " - thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()", " - thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow", " - scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker", " - scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32", " - drm/hyperv: validate resolution_count and fix WIN8 fallback", " - drm/hyperv: validate VMBus packet size in receive callback", " - drm/i915: Fix potential UAF in TTM object purge", " - drm/amd/pm/si: Disregard vblank time when no displays are connected", " - serial: altera_jtaguart: handle uart_add_one_port() failures", " - serial: qcom-geni: fix UART_RX_PAR_EN bit position", " - serial: sh-sci: fix memory region release in error path", " - serial: zs: Fix swapped RI/DSR modem line transition counting", " - serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma", " - drm/amdkfd: fix NULL pointer bug in svm_range_set_attr", " - drm/amdkfd: fix a vulnerability of integer overflow in kfd debugger", " - drm/amdkfd: Check for pdd drm file first in CRIU restore path", " - serial: dz: Fix bootconsole message clobbering at chip reset", " - serial: dz: Fix bootconsole handover lockup", " - serial: dz: Convert to use a platform device", " - serial: zs: Fix bootconsole handover lockup", " - serial: zs: Switch to using channel reset", " - serial: zs: Convert to use a platform device", " - USB: serial: cypress_m8: fix memory corruption with small endpoint", " - USB: serial: digi_acceleport: fix memory corruption with small endpoints", " - xhci: tegra: Fix ghost USB device on dual-role port unplug", " - iommu: Skip PASID validation for devices without PASID capability", " - x86/boot: Disable stack protector for early boot code", " - rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg", " - rxrpc: Fix RESPONSE packet verification to extract skb to a linear", " buffer", " - serdev: Provide a bustype shutdown function", " - Bluetooth: hci_qca: Migrate to serdev specific shutdown function", " - Bluetooth: hci_qca: Convert timeout from jiffies to ms", " - ALSA: scarlett2: Return ENOSPC for out-of-bounds flash writes", " - ALSA: scarlett2: Allow flash writes ending at segment boundary", " - mm/memory: fix spurious warning when unmapping device-private/exclusive", " pages", " - platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery", " - net: hsr: defer node table free until after RCU readers", " - mptcp: pm: fix ADD_ADDR timer infinite retry on option space", " insufficient", " - ice: fix VF queue configuration with low MTU values", " - mptcp: cleanup fallback dummy mapping generation", " - mptcp: reset rcv wnd on disconnect", " - arm64: tlb: Flush walk cache when unsharing PMD tables", " - octeontx2-pf: avoid double free of pool->stack on AQ init failure", " - mptcp: introduce the mptcp_init_skb helper", " - mptcp: handle first subflow closing consistently", " - mptcp: do not drop partial packets", " - mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()", " - iio: chemical: scd30: Use guard(mutex) to allow early returns", " - iio: chemical: scd30: fix division by zero in write_raw", " - iio: dac: ad5686: fix ref bit initialization for single-channel parts", " - ALSA: firewire-motu: Protect register DSP event queue positions", " - usb: dwc3: xilinx: fix error handling in zynqmp init error paths", " - usb: musb: omap2430: Fix use-after-free in omap2430_probe()", " - usb: typec: ucsi: Check if power role change actually happened before", " handling", " - thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()", " - usb: typec: ucsi: Don't update power_supply on power role change if not", " connected", " - hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with", " pmbus_lock", " - hwmon: (pmbus/adm1266) serialize NVMEM blackbox read with pmbus_lock", " - hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock", " - mm: perform all memfd seal checks in a single place", " - mm/memfd: fix spelling and grammatical issues", " - memfd: deny writeable mappings when implying SEAL_WRITE", " - usb: core: Fix SuperSpeed root hub wMaxPacketSize", " - Upstream stable to v6.12.93", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43331", " - x86/kexec: Disable KCOV instrumentation after load_segments()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52943", " - net: skbuff: fix missing zerocopy reference in pskb_carve helpers", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53358", " - Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52923", " - ipc: limit next_id allocation to the valid ID range", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2025-68768", " - inet: frags: flush pending skbs in fqdir_pre_exit()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43303", " - mm/page_alloc: clear page->private in free_pages_prepare()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52934", " - batman-adv: tvlv: reject oversized TVLV packets", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52913", " - batman-adv: v: stop OGMv2 on disabled interface", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46322", " - tun: free page on build_skb failure in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46321", " - tun: free page on short-frame rejection in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52927", " - netfilter: ebtables: fix OOB read in compat_mtw_from_user", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43219", " - net: cpsw_new: Fix potential unregister of netdev that has not been", " registered yet", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-45930", " - net: mctp: ensure our nlmsg responses are initialised", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53080", " - net/sched: cls_fw: fix NULL dereference of \"old\" filters before change()", "", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Enable CONFIG_ARM64_ERRATUM_4118414", "", " * CVE-2025-10263", " - arm64: cputype: Add C1-Ultra definitions", " - arm64: cputype: Add C1-Premium definitions", "", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", "", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", "", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", "", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", "", " * CVE-2026-63886", " - scsi: target: iscsi: Validate CHAP_R length before base64 decode", "", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", "", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", "", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", "", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", "", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", "", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", "", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", "", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", "", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", "", " * CVE-2026-64000", " - net: hsr: fix potential OOB access in supervision frame handling", "", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", "", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", "", " * CVE-2026-53131", " - netfilter: require Ethernet MAC header before using eth_hdr()", "" ], "package": "linux", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:47:58 +0300" } ], "notes": "linux-modules-6.8.0-147-generic version '6.8.0-147.147' (source package linux version '6.8.0-147.147') was added. linux-modules-6.8.0-147-generic version '6.8.0-147.147' has the same source package name, linux, as removed package linux-headers-6.8.0-142. As such we can use the source package version of the removed package, '6.8.0-142.142', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-tools-6.8.0-147", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-147.147 -proposed tracker (LP: #2168142)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026)", " - platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug", " - selftests/bpf: Add tests for ld_{abs,ind} failure path in subprogs", " - drm/virtio: fix deadlock in display_info_cb by removing hotplug from", " dequeue worker", " - mtd: mtdswap: remove debugfs stats file on teardown", " - seqlock: Cure some more scoped_seqlock() optimization fails", " - seqlock: Allow KASAN to fail optimizing", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/umem: Add support for creating pinned DMABUF umem with a given dma", " device", " - RDMA/umem: Introduce an option to revoke DMABUF umem", " - RDMA/umem: Add ib_umem_dmabuf_get_pinned_and_lock helper", " - RDMA/umem: Move umem dmabuf revoke logic into helper function", " - RDMA/umem: Add pinned revocable dmabuf import interface", " - RDMA/umem: Add helpers for umem dmabuf revoke lock", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - selftests/alsa: Fix memory leak in find_controls error path", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: cs42l43: Correct report for forced microphone jack", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - sched/vtime: Get rid of generic vtime_task_switch() implementation", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - can: j1939: fix lockless local-destination check", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - crypto: rsa-pkcs1pad: Don't WARN on an empty digest", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - wifi: ath11k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - wifi: ath12k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - ASoC: cs35l56: Don't use devres to unregister component", " - ASoC: cs35l56: Fix potential probe() deadlock", " - ASoC: cs35l56: Use complete_all() to signal init_completion", " - wifi: iwlwifi: mvm: validate SAR GEO response payload size", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - hwmon: (asus-ec-sensors) fix looping over banks while reading from EC", " - hwmon: (asus-ec-sensors) fix EC read intervals", " - hwmon: (asus-ec-sensors) add missed handle for ENOMEM", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - pds_core: yield the CPU while waiting for the adminq to drain", " - pds_core: order completion reads after the ownership check", " - pds_core: check for workqueue allocation failure", " - tls: device: push pending open record on splice EOF", " - selftest: af_unix: Add Kconfig file.", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - amt: make the head writable before rewriting the L2 header", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: dpaa: fix mode setting", " - iomap: correct the range of a partial dirty clear", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - net: stmmac: enable the MAC on link up for all supported speeds", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - ppp: use IFF_NO_QUEUE in virtual interfaces", " - ppp: convert to percpu netstats", " - ppp: enable TX scatter-gather", " - ppp: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: fix LAG recipe to profile association", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't", " at 0 (v2)", " - drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nxp: imx8-isi: Clean up already-initialized pipes on probe", " failure", " - media: nxp: imx8-isi: Fix missing v4l2_subdev_cleanup() in pipe init", " error path", " - media: nxp: imx8-isi: Fix scale factor calculation for hardware rounding", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vivid: add vivid_update_reduced_fps()", " - media: vpif_capture: fix OF node reference imbalance", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - LoongArch: Fix oops during single-step debugging", " - x86/boot/compressed: Disable jump tables", " - serial: sc16is7xx: implement gpio get_direction() callback", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - ice: use READ_ONCE() to access cached PHC time", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amd/display: Fix dcn32 DTB DTO update breaking live pixel rate", " sources", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - net: pcs: xpcs: fix SGMII state reading", " - bpf: drop bpf_lsm_getselfattr from hook list", " - udmabuf: Do not create malformed scatterlists", " - i2c: davinci: Unregister cpufreq notifier on probe failure", " - VFS/audit: introduce kern_path_parent() for audit", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - rxrpc: Pull out certain app callback funcs into an ops table", " - fbcon: Rename struct fbcon_ops to struct fbcon_par", " - fbcon: Use correct type for vc_resize() return value", " - rxrpc: Don't need barrier for ->tx_bottom and ->acks_hard_ack", " - rxrpc: Use irq-disabling spinlocks between app and I/O thread", " - rxrpc: Fix notification vs call-release vs recvmsg", " - rxrpc: Fix socket notification race", " - vduse: Use fixed 4KB bounce pages for non-4KB page size", " - vduse: remove unused vaddr parameter of vduse_domain_free_coherent", " - vduse: take out allocations from vduse_dev_alloc_coherent", " - octeontx2: Annotate mmio regions as __iomem", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - fbdev/efifb: Replace references to global screen_info by local pointer", " - ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable()", " - ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe()", " - ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb", " - ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - netfilter: nft_set_pipapo: use GFP_KERNEL for insertions", " - netfilter: nft_set_pipapo: move prove_locking helper around", " - netfilter: nft_set_pipapo: make pipapo_clone helper return NULL", " - netfilter: nft_set_pipapo: prepare walk function for on-demand clone", " - netfilter: nft_set_pipapo: merge deactivate helper into caller", " - netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone", " - netfilter: nft_set_pipapo: move cloning of match info to insert/removal", " path", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_tables: Remove unused nft_reduce_is_readonly()", " - netfilter: nf_tables: remove register tracking infrastructure", " - NFSD: pass nfsd_file to nfsd_iter_read()", " - sunrpc: allocate a separate bvec array for socket sends", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - dma: dw-edma: Fix build warning in dw_edma_pcie_probe()", " - dmaengine: dw-edma: Fix confusing cleanup.h syntax", " - platform/x86: dell-smbios: Move request functions for reuse", " - i2c: imx: separate atomic, dma and non-dma use case", " - nfs: remove dead code for the old swap over NFS implementation", " - ovl: use linked upper dentry in copy-up tmpfile", " - bootconfig: do not put quotes on cmdline items unless necessary", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - rxrpc: Disable IRQ, not BH, to take the lock for ->attend_link", " - netfilter: nft_quota: use atomic64_xchg for reset", " - soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE", " - wifi: cfg80211: pass net_device to .set_monitor_channel", " - wifi: cfg80211: define and use wiphy guard", " - wifi: cfg80211: derive S1G beacon TSF from S1G fields", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - smb: move some duplicate definitions to common/cifsglob.h", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - wifi: mt76: mt7925: extend mt7925_mcu_bss_he_tlv for per-link BSS", " - ovl: fix trusted xattr escape prefix matching", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - dpll: add clock quality level attribute and op", " - net/mlx5: DPLL, Add clock quality level op implementation", " - net/mlx5: Remove newline at the end of a netlink error message", " - net/mlx5: Refactor EEPROM query error handling to return status", " separately", " - octeontx2-pf: tc: fix egress ratelimiting", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm/displayid: move drm_displayid.h to drm_displayd_internal.h", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - ALSA: timer: drain a slave's callback before its master detaches it", " - ALSA: timer: don't re-enter an instance callback that is still running", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - sysctl: treewide: constify ctl_table_header::ctl_table_arg", " - ceph: fix refcount leak in ceph_readdir()", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - net: move skb_gro_receive_list from udp to core", " - net: add pskb_may_pull() to skb_gro_receive_list()", " - vsock/virtio: collapse receive queue under memory pressure", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - xfs: add an explicit owner field to xfs_da_args", " - xfs: factor out xfs_attr3_leaf_init", " - xfs: don't replace the wrong part of the cow fork", " - rxrpc: Fix CPU time starvation in I/O thread", " - ASoC: mediatek: mt8183-afe-pcm: Shorten memif_data table using macros", " - ASoC: mediatek: mt8183-afe-pcm: Support >32 bit DMA addresses", " - tcp: Decrement tcp_md5_needed static branch", " - nvmet: Introduce nvmet_req_transfer_len()", " - block: add helper add_disk_final()", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections", " - Bluetooth: hci_core: Fix not accounting for BIS/CIS/PA links separately", " - afs: Improve server refcount/active count tracing", " - afs: Make afs_lookup_cell() take a trace note", " - afs: Drop the net parameter from afs_unuse_cell()", " - rxrpc: Allow the app to store private data on peer structs", " - afs: Use the per-peer app data provided by rxrpc", " - afs: Fix afs_server ref accounting", " - afs: Simplify cell record handling", " - afs: Fix dynamic lookup to fail on cell lookup failure", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - lib/string_choices: Add str_plural() helper", " - USB: gadget: Use str_enable_disable-like helpers", " - usb: musb: omap2430: clean up probe error handling", " - net/mlx5e: Fix NULL pointer dereference in ioctl module EEPROM query", " - rxrpc: Fix locking issues with the peer record hash", " - wifi: nl80211: fix nl80211_start_radar_detection return value", " - afs: Set vllist to NULL if addr parsing fails", " - dpll: fix clock quality level reporting", " - afs: Fix delayed allocation of a cell's anonymous key", " - afs: handle CB.InitCallBackState3 requests without a server record", " - Bluetooth: hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK", " - Bluetooth: hci_conn: Fix not cleaning up Broadcaster/Broadcast Source", " - Bluetooth: hci_conn: Remove redundant memset after kzalloc", " - Bluetooth: hci_conn: Fix not cleaning up PA_LINK connections", " - Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()", " - afs: Fix uninit var in afs_alloc_anon_key()", " - Upstream stable to v6.6.148, v6.12.101", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72168", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72213", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72244", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53078", " - bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2025-40098", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_get_acpi_mute_state()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68372", " - usb: core: port: Deattach Type-C connector on component unbind", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72175", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45901", " - netfilter: nf_tables: revert commit_mutex usage in reset path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45897", " - netfilter: nft_counter: serialize reset with spinlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72015", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72017", " - net: macb: drop in-flight Tx SKBs on close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72030", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72023", " - octeontx2-pf: fix SQB pointer leak on init failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72040", " - ipmi: fix refcount leak in i_ipmi_request()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72045", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72062", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72051", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72070", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72142", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72147", " - dmaengine: dw-edma-pcie: Reject devices without driver data", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72254", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72253", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72260", " - ASoC: mediatek: mt8192: Check runtime resume during probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72305", " - VDUSE: avoid leaking information to userspace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64205", " - i2c: i801: fix hardware state machine corruption in error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64280", " - fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72146", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72124", " - can: isotp: serialize TX state transitions under so->rx_lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72125", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72115", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72117", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72116", " - can: bcm: fix stale rx/tx ops after device removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72113", " - can: bcm: add missing device refcount for CAN filter removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72114", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72119", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72118", " - can: bcm: fix CAN frame rx/tx statistics", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72121", " - can: bcm: add locking when updating filter and timer values", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53090", " - bpf: Fix ld_{abs,ind} failure path analysis in subprogs", "", " * test_vxlan_vnifiltering.sh from ubuntu_kselftests_net failed on linux-", " oem-6.8 (with ipv6 default rdst) (LP: #2071590)", " - selftests: net: use slowwait to make sure IPv6 setup finished", "", " * ubuntu_bpf failed to build in noble (error: redefinition of", " 'stack_load_preserves_const_precision') (LP: #2160493)", " - SAUCE: Revert \"selftests/bpf: validate fake register spill/fill", " precision backtracking logic\"", "", " * CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", "", " * Backport: \"mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios\"", " (LP: #2162917)", " - mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios", "", " * qrtr: ns: node limit of 64 breaks QRTR routing on large multi-node", " deployments (LP: #2165140)", " - net: qrtr: ns: Raise node count limit to 512", "", " * [UBUNTU 24.04] kernel: CPU hotplug unsupported by CPUMF (LP: #2165732)", " - s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks", "", " * CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", "", " * CVE-2025-38563", " - perf/core: Prevent VMA split of buffer mappings", "", " * CVE-2025-38565", " - perf/core: Exit early on perf_mmap() fail", "", " * CVE-2025-38187", " - drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()", "", " * CVE-2025-38069", " - PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops", "", " * CVE-2025-40014", " - objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()", "", " * CVE-2025-21985", " - drm/amd/display: Fix out-of-bound accesses", "", " * CVE-2024-56552", " - drm/xe/guc_submit: fix race around suspend_pending", "", " * CVE-2025-21687", " - vfio/platform: check the bounds of read/write syscalls", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237)", " - ext4: fix fd leak in EXT4_IOC_MOVE_EXT cross-sb validation", " - mm: refactor mm_access() to not return NULL", " - Upstream stable to v6.6.146, v6.12.98, v6.6.147, v6.12.99, v6.12.100", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237) //", " CVE-2026-64560", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995)", " - bpf, arm64: Reject out-of-range B.cond targets", " - nfsd: release layout stid on setlease failure", " - Bluetooth: btmtk: apply the common btmtk_fw_get_filename", " - Bluetooth: btmtk: Fix failed to send func ctrl for MediaTek devices.", " - Bluetooth: btmtk: Fix wait_on_bit_timeout interruption during shutdown", " - userfaultfd: gate must_wait writability check on pte_present()", " - perf: Fix dangling cgroup pointer in cpuctx backport", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error", " - device property: initialize the remaining fields of fwnode_handle in", " fwnode_init()", " - f2fs: validate orphan inode entry count", " - f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode", " - f2fs: fix potential deadlock in f2fs_balance_fs()", " - f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()", " - f2fs: fix listxattr handling of corrupted xattr entries", " - block: Avoid mounting the bdev pseudo-filesystem in userspace", " - i2c: core: fix irq domain leak on adapter registration failure", " - i2c: core: fix hang on adapter registration failure", " - i2c: core: fix NULL-deref on adapter registration failure", " - i2c: core: fix adapter debugfs creation", " - fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()", " - NFSv4/flexfiles: reject zero filehandle version count", " - locking/rtmutex: Make sure we wake anything on the wake_q when we", " release the lock->wait_lock", " - bonding: fix xfrm offload feature setup on active-backup mode", " - mm/vmscan: flush deferred TLB before freeing large folios", " - perf trace beauty fcntl: Fix build with older kernel headers", " - ACPI: CPPC: Suppress UBSAN warning caused by field misuse", " - ACPI: NFIT: core: Fix possible NULL pointer dereference", " - perf/core: Detach event groups during remove_on_exec", " - arm64: sysreg: Add layout for ID_AA64MMFR4_EL1", " - virtio_net: Support dynamic rss indirection table size", " - LoongArch: Add PIO for early access before ACPI PCI root register", " - usb: gadget: function: rndis: add length check to response query", " - usb: gadget: function: rndis: add length check for header", " - iio: accel: bmc150: clamp the device-reported FIFO frame count", " - iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error", " - iio: adc: lpc32xx: Initialize completion before requesting IRQ", " - iio: adc: ti-ads124s08: Return reset GPIO lookup errors", " - iio: chemical: scd30: Cleanup initializations and fix sign-extension bug", " - iio: event: Fix event FIFO reset race", " - iio: gyro: bmg160: bail out when bandwidth/filter is not in table", " - iio: gyro: bmg160: wait full startup time after mode change at probe", " - iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ", " - iio: imu: st_lsm6dsx: deselect shub page before reading whoami", " - iio: light: al3010: fix incorrect scale for the highest gain range", " - iio: light: gp2ap002: fix runtime PM leak on read error", " - iio: light: opt3001: fix missing state reset on timeout", " - iio: light: tsl2591: return actual error from probe IRQ failure", " - iio: light: veml6030: fix channel type when pushing events", " - iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call", " - iio: temperature: ltc2983: Fix reinit_completion() called after", " conversion start", " - ALSA: virtio: Add missing 384 kHz PCM rate mapping", " - ALSA: ymfpci: check snd_ctl_new1() return value", " - ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input", " parser", " - ALSA: cmipci: check snd_ctl_new1() return value", " - ALSA: es1938: check snd_ctl_new1() return value", " - ALSA: firewire: isight: bound the sample count to the packet payload", " - ALSA: gus: check snd_ctl_new1() return value", " - ALSA: ice1712: check snd_ctl_new1() return value", " - ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()", " - ALSA: usb-audio: avoid kobject path lookup in DualSense match", " - ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()", " - ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch", " put callbacks", " - ALSA: usb-audio: Update Babyface Pro control caches only after", " successful writes", " - ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful", " writes", " - vfio/pci: Use a private flag to prevent power state change with VFs", " - vfio/pci: Latch disable_idle_d3 per device", " - vfio/pci: Release the VGA arbiter client on register_device() failure", " - vfio/pci: Fix racy bitfields and tighten struct layout", " - vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc", " - Bluetooth: btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB", " - Bluetooth: btusb: fix use-after-free on registration failure", " - Bluetooth: btusb: fix use-after-free on marvell probe failure", " - Bluetooth: btusb: fix wakeup source leak on probe failure", " - binder: fix UAF in binder_thread_release()", " - binder: fix UAF in binder_free_transaction()", " - usb: xhci: Fix sleep in atomic context in xhci_free_streams()", " - PCI: altera: Do not dispose parent IRQ mapping", " - mm/damon/ops-common: handle extreme intervals in damon_hot_score()", " - netfilter: ipset: fix race between dump and ip_set_list resize", " - virtio-mmio: fix device release warning on module unload", " - hwrng: virtio: clamp device-reported used.len at copy_data()", " - USB: chaoskey: Fix slab-use-after-free in chaoskey_release()", " - usb: dwc3: run gadget disconnect from sleepable suspend context", " - 6lowpan: fix NHC entry use-after-free on error path", " - tipc: fix out-of-bounds read in broadcast Gap ACK blocks", " - staging: vme_user: bound slave read/write to the kern_buf size", " - smb: client: restrict implied bcc[0] exemption to responses without data", " area", " - staging: vme_user: fix location monitor leak in fake bridge", " - staging: vme_user: fix location monitor leak in tsi148 bridge", " - media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe", " - staging: media: atomisp: reduce load_primary_binaries() stack usage", " - staging: rtl8723bs: fix heap buffer overflow in", " rtw_cfg80211_set_wpa_ie()", " - staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()", " - staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop", " - staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop", " - staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and", " join_cmd_hdl()", " - staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop", " - staging: rtl8723bs: fix OOB write in HT_caps_handler()", " - crypto: amlogic - avoid double cleanup in meson_crypto_probe()", " - ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then", " SMB2_CANCEL", " - net: af_key: initialize alg_key_len for IPComp states", " - audit: Fix data races of skb_queue_len() readers on audit_queue", " - Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete", " - debugobjects: Plug race against a concurrent OOM disable", " - fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns", " - NTB: epf: Avoid calling pci_irq_vector() from hardirq context", " - io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item", " - ipv4: igmp: remove multicast group from hash table on device destruction", " - net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes", " - mfd: cros_ec: Delay dev_set_drvdata() until probe success", " - mm: shrinker: fix NULL pointer dereference in debugfs", " - netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump", " - f2fs: bound i_inline_xattr_size for non-inline-xattr inodes", " - drm/amd: Fix set but not used warnings", " - apparmor: advertise the tcp fast open fix is applied", " - nfsd: move name lookup out of nfsd4_list_rec_dir()", " - nfsd: change nfs4_client_to_reclaim() to allocate data", " - arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative", " - arm64: Fix early handling of FEAT_E2H0 not being implemented", " - KVM: arm64: Initialize HCR_EL2.E2H early", " - arm64: Revamp HCR_EL2.E2H RES1 detection", " - arm64: sysreg: Correct sign definitions for EIESB and DoubleLock", " - iio: adc: spear: Initialize completion before requesting IRQ", " - iio: imu: inv_icm42600: fix timestamp clock period by using lower value", " - ALSA: usb-audio: Roll back quirk control caches on write errors", " - usb: typec: tcpci_rt1711h: unregister TCPCI port with devres", " - gpio: eic-sprd: use raw_spinlock_t in the irq startup path", " - netfilter: ebtables: module names must be null-terminated", " - netfilter: ebtables: terminate table name before find_table_lock()", " - Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()", " - Bluetooth: bnep: pin L2CAP connection during netdev registration", " - Bluetooth: btnxpuart: Fix out-of-bounds firmware read in", " nxp_recv_fw_req_v3()", " - Bluetooth: fix UAF in bt_accept_dequeue()", " - Bluetooth: L2CAP: validate option length before reading conf opt value", " - fs/ntfs3: fsync files by syncing parent inodes", " - fs/ntfs3: zero-fill folios beyond i_valid in ntfs_read_folio()", " - fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()", " - coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer()", " - smb/client: Fix error code in smb2_aead_req_alloc()", " - ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE", " - ksmbd: add a permission check for FSCTL_SET_ZERO_DATA", " - ksmbd: serialize QUERY_DIRECTORY requests per file", " - ksmbd: require source read access for duplicate extents", " - ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock", " cancellation", " - ksmbd: add a WRITE_DAC/WRITE_OWNER check to SMB2 SET_INFO SECURITY", " - ksmbd: run set info with opener credentials", " - ksmbd: enforce FILE_READ_ATTRIBUTES on SMB_FIND_FILE_POSIX_INFORMATION", " - ksmbd: add per-handle permission check to FILE_LINK_INFORMATION", " - ksmbd: use opener credentials for delete-on-close", " - smb: client: fix query directory replay double-free", " - smb: client: fix query_info() replay double-free", " - smb: client: fix double-free in SMB2_ioctl() replay", " - smb: client: fix change notify replay double-free", " - smb: client: fix double-free in SMB2_flush() replay", " - smb: client: fix double-free in SMB2_open() replay", " - smb: client: fix double-free in SMB2_close() replay", " - smb: client: Fix next buffer leak in receive_encrypted_standard()", " - smb: client: use unaligned reads in parse_posix_ctxt()", " - smb: client: harden POSIX SID length parsing", " - smb: client: mask server-provided mode to 07777 in modefromsid", " - OPP: of: Fix potential memory leak in opp_parse_supplies()", " - firmware_loader: fix device reference leak in firmware_upload_register()", " - cpufreq: intel_pstate: Sync policy->cur during CPU offline", " - sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT", " - cpufreq: Fix hotplug-suspend race during reboot", " - cpufreq: pcc: fix use-after-free and double free in _OSC evaluation", " - posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path", " - clocksource/drivers/timer-tegra186: Fix support for multiple watchdog", " instances", " - X.509: Fix validation of ASN.1 certificate header", " - tools/mm/slabinfo: Fix trace disable logic inversion", " - tools/mm/slabinfo: fix total_objects attribute name", " - HID: wacom: stop hardware after post-start probe failures", " - HID: letsketch: fix UAF on inrange_timer at driver unbind", " - HID: lg-g15: cancel pending work on remove to fix a use-after-free", " - HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte", " reads", " - hfs/hfsplus: zero-initialize buffer in hfs_bnode_read", " - nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers", " - media: mtk-jpeg: cancel workqueue on release for supported platforms", " only", " - xfs: use null daddr for unset first bad log block", " - xfs: fix unreachable BIGTIME check in dquot flush validation", " - bpf: Reject fragmented frames in devmap", " - bpf: Restore sysctl new-value from 1 to 0", " - net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()", " - usb: cdc_acm: Add quirk for Uniden BC125AT scanner", " - usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()", " - USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub", " - usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()", " - usb: free iso schedules on failed submit", " - usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler", " - usb: gadget: udc: Fix use-after-free in gadget_match_driver", " - usb: gadget: f_printer: take kref only for successful open", " - USB: idmouse: fix use-after-free on disconnect race", " - USB: ldusb: fix use-after-free on disconnect race", " - USB: iowarrior: fix use-after-free on disconnect", " - USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD", " - USB: legousbtower: fix use-after-free on disconnect race", " - usb: sl811-hcd: disable controller wakeup on remove", " - USB: storage: include US_FL_NO_SAME in quirks mask", " - USB: misc: uss720: unregister parport on probe failure", " - usb: mtu3: unmap request DMA on queue failure", " - USB: serial: keyspan_pda: fix information leak", " - USB: serial: option: add Telit Cinterion FE990D50 compositions", " - USB: serial: digi_acceleport: fix broken rx after throttle", " - USB: serial: digi_acceleport: fix hard lockup on disconnect", " - USB: serial: digi_acceleport: fix write buffer corruption", " - USB: ulpi: fix memory leak on registration failure", " - USB: usb-storage: ene_ub6250: restore media-ready check", " - usbip: tools: support SuperSpeedPlus devices", " - usbip: vudc: fix NULL deref in vep_dequeue()", " - usb: typec: anx7411: use devm_pm_runtime_enable()", " - usb: typec: class: drop PD lookup reference", " - usb: typec: tcpm: Validate SVID index in svdm_consume_modes()", " - usb: typec: ucsi: Invert DisplayPort role assignment", " - usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt", " mode", " - usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove", " - usb: typec: ucsi: cancel pending work on system suspend", " - iio: temperature: ltc2983: Fix n_wires default bypassing rotation check", " - PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining", " - udf: validate free block extents against the partition length", " - udf: validate VAT header length against the VAT inode size", " - udf: validate sparing table length as an entry count, not a byte count", " - hwrng: jh7110 - fix refcount leak in starfive_trng_read()", " - dm-ioctl: report an error if a device has no table", " - nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace", " disks", " - btrfs: do not trim a device which is not writeable", " - partitions: aix: bound the pp_count scan to the ppe array", " - isofs: bound Rock Ridge symlink components to the SL record", " - crypto: af_alg - Remove zero-copy support from skcipher and aead", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps again", " - crypto: ecc - Fix carry overflow in vli multiplication", " - crypto: pcrypt - restore callback for non-parallel fallback", " - crypto: drbg - Fix returning success on failure in CTR_DRBG", " - crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels", " - crypto: drbg - Fix the fips_enabled priority boost", " - crypto: qat - validate RSA CRT component lengths", " - crypto: talitos - use dma_sync_single_for_cpu() before reading", " descriptor header", " - crypto: talitos - add chaining of arbitrary number of descriptor for the", " SEC1", " - crypto: talitos - move dma unmapping code in flush_channel() into a", " standalone dma_unmap_request() function", " - crypto: talitos - move dma mapping code in talitos_submit() into a", " standalone dma_map_request() function", " - crypto: talitos - move code in current_desc_hdr() into a standalone", " function", " - crypto: talitos/hash - prepare SEC1 descriptor chaining, remove", " additional descriptor", " - crypto: talitos/hash - use descriptor chaining for SEC1 instead of", " workqueue", " - crypto: talitos/hash - drop workqueue mechanism for SEC1", " - crypto: talitos/hash - rename first_desc/last_desc to", " first_request/last_request", " - crypto: talitos/hash - remove useless wrapper", " - crypto: talitos/hash - fix SEC2 64k - 1 ahash request limitation", " - arm64: fpsimd: Fix type mismatch in sme_{save,load}_state()", " - spi: fsl-lpspi: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - spi: fsl-lpspi: terminate the RX channel on TX prepare failure path", " - EDAC/i10nm: Don't fail probing if ADXL is missing", " - watchdog: apple: Add \"apple,t8103-wdt\" compatible", " - tracing: Prevent out-of-bounds read in glob matching", " - NFSv4: include MAY_WRITE in open permission mask for O_TRUNC", " - module: decompress: check return value of module_extend_max_pages()", " - exfat: bound uniname advance in exfat_find_dir_entry()", " - NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()", " - KVM: VMX: Refresh GUEST_PENDING_DBG_EXCEPTIONS.BS on all injected #DBs", " - KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest", " mode", " - udmabuf: fix DMA direction mismatch in release_udmabuf()", " - i2c: core: fix adapter deregistration race", " - i2c: mpc: Fix timeout calculations", " - i2c: stm32f7: truncate clock period instead of rounding it", " - Input: synaptics-rmi4 - unregister function handlers on physical driver", " registration failure", " - Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count", " - Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count", " - Input: elan_i2c - prevent division by zero and arithmetic underflow", " - Input: goodix - clamp the device-reported contact count", " - Input: iforce - bound the device-reported force-feedback effect index", " - Input: mms114 - fix touch indexing for MMS134S and MMS136", " - Input: touchwin - reset the packet index on every complete packet", " - Input: mms114 - reject an oversized device packet size", " - Input: maplemouse - fix NULL pointer dereference in open()", " - Input: mms114 - fix multi-touch slot corruption", " - Input: maple_keyb - set driver data before registering input device", " - Input: maplemouse - set driver data before registering input device", " - Input: maplecontrol - set driver data before registering input device", " - RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", " - fuse: fix device node leak in cuse_process_init_reply()", " - fuse: re-lock request before returning from fuse_ref_folio()", " - smb: client: reject overlapping data areas in SMB2 responses", " - xfs: fail recovery on a committed log item with no regions", " - xfs: resample the data fork mapping after cycling ILOCK", " - smb/server: do not require delete access for non-replacing links", " - sched/fair: Only update stats for allowed CPUs when looking for dst", " group", " - KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU", " - KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove CRYPTO_DEV_SUN4I_SS_PRNG", " - crypto: crypto4xx - Remove ahash-related code", " - bpf: Support for hardening against JIT spraying", " - x86/bugs: Enable IBPB flush on BPF JIT allocation", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix sequence number when no EOF", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - dt-bindings: power: imx93: Add MIPI PHY power domain", " - serial: msm: Disable DMA for kernel console UART", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: Fix further netns teardown to cancel the preallocation charger", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/amdgpu: fix integer overflow in amdgpu_gem_align_pitch()", " - drm/radeon: fix integer overflow in radeon_align_pitch()", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " - libbpf: Report error when a negative kprobe offset is specified", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg", " warning", " - wifi: cfg80211: fix grammar in MLO group key error message", " - arm64: tegra: Fix Tegra234 MGBE PTP clock", " - dt-bindings: pinctrl: nvidia,tegra234: Add missing required block", " - drm/amdkfd: Validate CRIU-restored IDs before idr_alloc", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sama5d4_wdt: Fix WDDIS detection on SAM9X60 and SAMA7G5", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - media: v4l2-common: Add YUV24 format info", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " - dlm: fix add msg handle in send_queue ordered", " - nilfs2: fix backing_dev_info reference leak", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - evm: terminate and bound the evm_xattrs read buffer", " - thermal: hwmon: Fix critical temperature attribute removal", " - clk: scpi: Unregister child clock providers on remove", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - spi: hisi-kunpeng: Use dev_err_probe() for host registration failure", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/srpt: fix integer overflow in immediate data length check", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - driver core: Use mod_delayed_work to prevent lost deferred probe work", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - bus: sunxi-rsb: Always check register address validity", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: seq: midi: Serialize output teardown with event_input", " - pinctrl: cs42l43: Fix polarity on debounce", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " - drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X", " client is registered", " - drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove", " - gpu: host1x: Allow entries in BO caches to be freed", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - gpu: host1x: Fix iommu_map_sgtable() return value check", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Harden parse_vma_segs() path parsing", " - libbpf: Fix UAF in strset__add_str()", " - dax/kmem: account for partial discontiguous resource upon removal", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - rpmsg: use generic driver_override infrastructure", " - md/raid10: reset read_slot when reusing r10bio for discard", " - RDMA/siw: bound Read Response placement to the RREAD length", " - block: skip sync_blockdev() on surprise removal in bdev_mark_dead()", " - crypto: algif_skcipher - force synchronous processing", " - crypto: crypto4xx - Remove insecure and unused rng_alg", " - crypto: hisi-trng - Remove crypto_rng interface", " - bpf: Restrict JIT predictor flush to cBPF", " - bpf: Skip redundant IBPB in pack allocator", " - bpf: Prefer packs that won't trigger an IBPB flush on allocation", " - bpf: Prefer dirty packs for eBPF allocations", " - clk: scmi: Fix clock rate rounding", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - bitops: use common function parameter names", " - media: rockchip: rga: fix too small buffer size", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - scsi: ufs: Fix wrong value printed in unexpected UPIU response case", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " - mm/fake-numa: fix under-allocation detection in uniform split", " - ext2: fix ignored return value of generic_write_sync()", " - sched: restore timer_slack_ns when resetting RT policy on fork", " - lib/test_meminit: use && for bools", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: reject FITRIM ranges shorter than a cluster", " - ocfs2/dlm: require a ref for locking_state debugfs open", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - bpf: Check tail zero of bpf_prog_info", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - wifi: wcn36xx: fix heap overflow from oversized firmware HAL response", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " - wifi: wcn36xx: fix OOB read from short trigger BA firmware response", " - ALSA: seq: Fix partial userptr event expansion", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - scsi: target: Fix hexadecimal CHAP_I handling", " - scsi: target: Remove tcm_loop target reset handling", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " - hwspinlock: qcom: avoid uninitialized struct members", " - sched/fair: Fix cpu_util runnable_avg arithmetic", " - wifi: mt76: fix argument to ieee80211_is_first_frag()", " - wifi: mt76: mt7915: fix potential tx_retries underflow", " - wifi: mt76: mt7921: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - spi: meson-spifc: fix runtime PM leak on remove", " - ASoC: codecs: aw88261: fix incorrect masks for boost regs", " - vduse: hold vduse_lock across IDR lookup in open path", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " - vduse: Requeue failed read to send_list head", " - vhost/net: complete zerocopy ubufs only once", " - tools/virtio: check mmap return value in vringh_test", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - bonding: 3ad: fix mux port state on oper down", " - ext4: fix kernel BUG in ext4_write_inline_data_end", " - selftests/bpf: Fix bpf_iter/task_vma test", " - cxl/test: Fix integer overflow in mock LSA bounds checks", " - cxl/test: Zero out LSA backing memory to avoid leaking to user", " - of: cpu: add check in __of_find_n_match_cpu_property()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " - RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " - ASoC: fsl: fsl_audmix: Validate written enum values", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " - net/sched: cls_flow: Dont expose folded kernel pointers", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " - bridge: cfm: reject invalid CCM interval at configuration time", " - sctp: validate embedded address parameter length", " - net/sched: sch_hfsc: Don't make class passive twice", " - tipc: require net admin for TIPCv2 netlink mutators", " - tipc: prevent snt_unacked underflow on CONN_ACK", " - tipc: reject inverted service ranges from peer bindings", " - cxl/test: Add check after kzalloc() memory in alloc_mock_res()", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " - crypto: rng - Free default RNG on module exit", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - power: supply: core: fix supplied_from allocations", " - handshake: Require admin permission for DONE command", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - net: wwan: t7xx: check skb_clone in control TX", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - netfilter: nf_conncount: callers must hold rcu read lock", " - ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait()", " - cifs: remove all cifs files before kill super", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - tipc: fix UAF in tipc_l2_send_msg()", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - ionic: Fix check in ionic_get_link_ext_stats", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - coresight: cti: Fix DT filter signals silently ignored", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - PCI/ASPM: Don't reconfigure ASPM entering low-power state", " - PCI: Introduce named defines for PCI ROM", " - PCI: Check ROM header and data structure addr before accessing", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - mailbox: mtk-adsp: fix UAF during device teardown", " - staging: most: video: avoid double free on video register failure", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " - iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " - iio: tcs3472: power down chip on probe failure", " - clk: at91: keep securam node alive while mapping it", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - fs/ntfs3: add bounds check to run_get_highest_vcn()", " - fs/ntfs3: fix mount failure on 64K page-size kernels", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - pNFS/filelayout: fix cheking if a layout is striped", " - xprtrdma: Remove temp allocation of rpcrdma_rep objects", " - xprtrdma: Avoid 250 ms delay on backlog wakeup", " - xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot", " - xprtrdma: Post receive buffers after RPC completion", " - xprtrdma: Use sendctx DMA state for Send signaling", " - xprtrdma: Decouple req recycling from RPC completion", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - nfs: keep PG_UPTODATE clear after read errors in page groups", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Fix bcall rep leak and unbounded peek", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - apparmor: fix rawdata_f_data implicit flex array", " - apparmor: fix potential UAF in aa_replace_profiles", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - sparc: led: avoid trimming a newline from empty writes", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - spi: dw: fix wrong BAUDR setting after resume", " - xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO", " path", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " - PCI: iproc: Restore .map_irq() for the platform bus driver", " - spi: rpc-if: Use correct device for hardware reinitialization on resume", " - virtio-net: fix len check in receive_big()", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - flow_dissector: check device type before reading ETH_ADDRS", " - ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: Fix data race between add and dump in all hash types", " - netfilter: ipset: annotate \"pos\" for concurrent readers/writers", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash", " types", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - irqchip/crossbar: Fix parent domain resource leak", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - net: marvell: prestera: initialize err in prestera_port_sfp_bind", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " - net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths", " - octeontx2-af: mcs: Fix unsupported secy stats read", " - octeontx2-pf: Clear stats of all resources when freeing resources", " - octeontx2-pf: mcs: Fix mcs resources free on PF shutdown", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: Fix stack slot index in nospec checks", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()", " - ice: fix AQ error code comparison in ice_set_pauseparam()", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - ipv4: fib: Don't ignore error route in local/main tables.", " - bpf, lsm: Add disabled BPF LSM hook list", " - bpf: Disable xfrm_decode_session hook attachment", " - netfilter: nf_nat: avoid invalid nat_net pointer use on failed", " nf_nat_init()", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - netfilter: nft_compat: ebtables emulation must reject non-bridge targets", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - NTB: epf: Report 0-based doorbell vector via ntb_db_event()", " - NTB: epf: Fix doorbell bitmask and IRQ vector handling", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - net, bpf: check master for NULL in xdp_master_redirect()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - net: mvneta: re-enable percpu interrupt on resume", " - net: sungem: fix probe error cleanup", " - net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - net: enetc: check the number of BDs needed for xdp_frame", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - apparmor: check label build before no_new_privs test", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - net/sched: sch_teql: Introduce slaves_lock to avoid race condition and", " UAF", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - cxgb4: Fix decode strings dump for T6 adapters", " - virtio_net: disable cb when NAPI is busy-polled", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - ksmbd: reject undersized DACLs before parsing ACEs", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - pinctrl: meson: restore non-sleeping GPIO access", " - net/sched: hhf: clear heavy-hitter state on reset", " - fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid", " - afs: Fix error code in afs_extract_vl_addrs()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix vllist leak", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " - afs: Fix unchecked-length string display in debug statement", " - minix: avoid overflow in bitmap block count calculation", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: convert READ_ONCE(*ptep) to ptep_get(ptep)", " - arm64/mm: convert set_pte_at() to set_ptes(..., 1)", " - arm64/mm: convert ptep_clear() to ptep_get_and_clear()", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - selftests/hid: convert the hid_bpf selftests with struct_ops", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - gue: validate REMCSUM private option length", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " - amt: fix size calculation in amt_get_size()", " - Bluetooth: 6lowpan: hold L2CAP conn across debugfs control", " - Bluetooth: MGMT: Fix adv monitor add failure cleanup", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - ring-buffer: Fix event length with forced 8-byte alignment", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: move functions to avoid forward definitions", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " - ipv6: mcast: Replace locking comments with lockdep annotations.", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " - s390/zcrypt: Remove the empty file", " - cifs: validate DFS referral string offsets", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " - dm era: fix NULL pointer dereference in metadata_open()", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " - selftests/net: fix EVP_MD_CTX leak in tcp_mmap", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - octeontx2-af: fix VF bringup affecting PF promiscuous state", " - smb: client: fix overflow in passthrough ioctl bounds check", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " - ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put", " - ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc", " - ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get", " - ASoC: SOF: topology: validate vendor array size before parsing", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " - net: atm: reject out-of-range traffic classes in QoS validation", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " - fbdev: vesafb: fix memory leak in vesafb_probe()", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " - ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get", " - ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Release reserved memory on cleanup", " - ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_cluster: reject template conntracks in hash match", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - netfilter: nf_nat_sip: reload possible stale data pointer", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " - netfilter: ecache: fix inverted time_after() check", " - netfilter: xt_nat: reject unsupported target families", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - selinux: check connect-related permissions on TCP Fast Open", " - leds: uleds: Fix potential buffer overread", " - mfd: sm501: Fix reference leak on failed device registration", " - tools/power/x86/intel-speed-select: Harden daemon pidfile open", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " - x86/boot: Reject too long acpi_rsdp= values", " - perf/x86/amd/lbr: Fix kernel address leakage", " - s390/perf_cpum_cf: Add missing array_index_nospec() to", " __hw_perf_event_init()", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: bla: reacquire gw address after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: tt: avoid request storms during pending request", " - batman-adv: fix VLAN priority offset", " - batman-adv: frag: free unfragmentable packet", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: tt: prevent TVLV OOB check overflow", " - cifs: invalidate cfid on unlink/rename/rmdir", " - mfd: tps6586x: Fix OF node refcount", " - HID: playstation: validate num_touch_reports in DualShock 4 reports", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " - nvdimm/btt: Free arenas on btt_init() error paths", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - mm/damon/core: make charge_addr_from aware of end-address exclusivity", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " - fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " - riscv: cacheinfo: Fix node reference leak in populate_cache_leaves", " - mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs()", " - mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error", " - proc: only bump parent nlink when registering directories", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - mtd: rawnand: pl353: fix probe resource allocation", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " - mtd: rawnand: fix condition in 'nand_select_target()'", " - ocfs2: avoid moving extents to occupied clusters", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " - ocfs2: add journal NULL check in ocfs2_checkpoint_inode()", " - ocfs2: reject dinodes with non-canonical i_mode type", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " - fpga: dfl: add bounds check in dfh_get_param_size()", " - bus: mhi: ep: Protect mhi_ep_handle_syserr() in the error path", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - fpga: microchip-spi: fix zero header_size OOB read in", " mpf_ops_parse_header()", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86/amd/pmc: Check for intermediate wakeup in function", " - platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops", " - platform/x86/amd/pmc: Add delay_suspend module parameter", " - smb: client: use kvzalloc() for megabyte buffer in simple fallocate", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - ice: fix ice_init_link() error return preventing probe", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - tpm: Make the TPM character devices non-seekable", " - time: Fix off-by-one in compat settimeofday() usec validation", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " - sctp: validate STALE_COOKIE cause length before reading staleness", " - nvmet-rdma: handle inline data with a nonzero offset", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " - can: bcm: add missing rcu list annotations and operations", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - net: sparx5: unregister blocking notifier on init failure", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " - dm era: fix out-of-bounds memory access for non-zero start sector", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-ioctl: fix a possible overflow in list_version_get_info", " - dm-log: fix a bitset_size overflow on 32bit machines", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm_early_create: fix freeing used table on dm_resume failure", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - scsi: sg: Report request-table problems when any status is set", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - validate control endpoint type", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - Input: ims-pcu - fix race condition in reset_device sysfs callback", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " - net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio-f7188x: Add support for NCT6126D version B", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: wwan: t7xx: destroy DMA pool on CLDMA late init failure", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - net: ena: clean up XDP TX queues when regular TX setup fails", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " - ieee802154: admin-gate legacy LLSEC dump operations", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " - batman-adv: ensure minimal ethernet header on TX", " - batman-adv: clean untagged VLAN on netdev registration failure", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - espintcp: use sk_msg_free_partial to fix partial send", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: mpfs: fix counter upload completion condition", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - net: liquidio: fix BAR resource leak on PF number failure", " - hwmon: (occ) unregister sysfs devices outside occ lock", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - net: lan743x: Initialize eth_syslock spinlock before use", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - net: wwan: iosm: bound device offsets in the MUX downlink decoder", " - hwmon: (asus_atk0110) Check package count before accessing element", " - riscv: probes: save original sp in rethook trampoline", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - drbd: reject data replies with an out-of-range payload size", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " - pmdomain: imx: Fix i.MX8MP power notifier", " - pmdomain: imx: Fix i.MX8MP VC8000E power up sequence", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - Bluetooth: btrtl: validate firmware patch bounds", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - memstick: ms_block: reject a card that reports too many blocks", " - ipvs: fix more places with wrong ipv6 transport offsets", " - ipvs: reload ip header after head reallocation", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: mac80211: free ack status frame on TX header build failure", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " - mtd: onenand: samsung: report DMA completion timeouts", " - mtd: mchp23k256: use SPI match data for chip caps", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " - perf/x86/amd/brs: Fix kernel address leakage", " - ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup", " - ACPI: bus: Introduce devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Use devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Fix possible deadlock and missing notifications", " - iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - iio: invensense: remove redundant initialization of variable period", " - iio: invensense: fix timestamp glitches when switching frequency", " - iio: imu: inv_icm42600: stabilized timestamp in interrupt", " - iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading", " - iio: pressure: mpl115: fix runtime PM leak on read error", " - bitops: make BYTES_TO_BITS() treewide-available", " - iio: common: st_sensors: honour channel endianness in read_axis_data", " - ALSA: aoa: check snd_ctl_new1() return value", " - PCI: altera: Fix resource leaks on probe failure", " - vfio/mlx5: Fix racy bitfields and tighten struct layout", " - PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling", " - PCI: controller: Use dev_fwnode() instead of of_fwnode_handle()", " - PCI: mediatek: Convert bool to single quirks entry and bitmap", " - PCI: mediatek: Use generic MACRO for TPVPERL delay", " - PCI: mediatek: Fix IRQ domain leak when port fails to enable", " - PCI: Prevent resource tree corruption when BAR resize fails", " - PCI: Free saved list without holding pci_bus_sem", " - PCI: Fix restoring BARs on BAR resize rollback path", " - PCI: Add kerneldoc for pci_resize_resource()", " - PCI: Move Resizable BAR code to rebar.c", " - PCI: Skip Resizable BAR restore on read error", " - staging: rtl8723bs: core: move constants to right side in comparison", " - staging: rtl8723bs: fix spaces around binary operators", " - staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),", " rtw_get_wapi_ie(), and rtw_get_wps_attr()", " - crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()", " - Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref", " - mm/shrinker: do not hold RCU lock in shrinker_debugfs_count_show()", " - coresight: etb10: restore atomic_t for shared reading state", " - gpio: sch: use raw_spinlock_t in the irq startup path", " - media: nxp: imx8-isi: Convert to platform remove callback returning void", " - media: nxp: imx8-isi: use devm_pm_runtime_enable() to simplify code", " - media: nxp: imx8-isi: Fix use-after-free on remove", " - netfilter: ebtables: Use vmalloc_array() to improve code", " - netfilter: ebtables: zero chainstack array", " - Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - smb: client: Improve unlocking of a mutex in cifs_get_swn_reg()", " - smb: client: resolve SWN tcon from live registrations", " - ksmbd: use opener credentials for FSCTL mutations", " - ksmbd: centralize ksmbd_conn final release to plug transport leak", " - ksmbd: track the connection owning a byte-range lock", " - proc: rename proc_setattr to proc_nochmod_setattr", " - proc: protect ptrace_may_access() with exec_update_lock (FD links)", " - writeback: fix race between cgroup_writeback_umount() and", " inode_switch_wbs()", " - perf/x86/intel/uncore: Defer ADL global PMON enable to enable_box()", " - HID: add haptics page defines", " - HID: multitouch: fix out-of-bounds bit access on mt_io_flags", " - mm/slab: do not limit zeroing to orig_size when only red zoning is", " enabled", " - seqlock: Introduce scoped_seqlock_read()", " - seqlock: Change do_task_stat() to use scoped_seqlock_read()", " - proc: protect ptrace_may_access() with exec_update_lock (part 1)", " - treewide: Switch/rename to timer_delete[_sync]()", " - HID: appleir: fix UAF on pending key_up_timer in remove()", " - serial: 8250_mid: Disable DMA for selected platforms", " - hfs/hfsplus: prevent getting negative values of offset/length", " - hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length", " - bpf: Consistently use bpf_rcu_lock_held() everywhere", " - bpf: Allow LPM map access from sleepable BPF programs", " - usb: iowarrior: remove inherent race with minor number", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - usb: typec: tcpm: Fix VDM type for Enter Mode commands", " - crypto: atmel - Drop explicit initialization of struct", " i2c_device_id::driver_data to 0", " - crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A", " - usb: gadget: f_fs: initialize reset_work at allocation time", " - nvmet: return DHCHAP status codes from nvmet_setup_auth()", " - nvmet-auth: validate reply message payload bounds against transfer", " length", " - usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile", " - btrfs: check and set EXTENT_DELALLOC_NEW before clearing EXTENT_DELALLOC", " - crypto: qat - fix restarting state leak on allocation failure", " - audit: add audit_log_nf_skb helper function", " - audit: fix potential integer overflow in audit_log_n_hex()", " - regulator: scmi: Simplify with scoped for each OF child loop", " - regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()", " - mm: do file ownership checks with the proper mount idmap", " - exfat: move free cluster out of exfat_init_ext_entry()", " - exfat: remove unnecessary read entry in __exfat_rename()", " - exfat: rename argument name for exfat_move_file and exfat_rename_file", " - exfat: add exfat_get_dentry_set_by_ei() helper", " - exfat: move exfat_chain_set() out of __exfat_resolve_path()", " - exfat: preserve benign secondary entries during rename and move", " - btrfs: fix false IO failure after falling back to buffered write", " - btrfs: fix incorrect buffered IO fallback for append direct writes", " - Bluetooth: hci_core: Enable buffer flow control for SCO/eSCO", " - Bluetooth: separate CIS_LINK and BIS_LINK link types", " - Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - seqlock: fix scoped_seqlock_read kernel-doc", " - Bluetooth: hci_core: Remove check of BDADDR_ANY in", " hci_conn_hash_lookup_big_state", " - Bluetooth: hci_sync: Fix attempting to send HCI_Disconnect to BIS handle", " - Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote", " netdev", " - selftests/hid: ensure CKI can compile our new tests on old kernels", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error harder", " - Bluetooth: btmtk: remove #ifdef around declarations", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - jiffies: Define secs_to_jiffies()", " - jiffies: Cast to unsigned long in secs_to_jiffies() conversion", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - tools/testing: add linux/args.h header and fix radix, VMA tests", " - selftests/bpf: Add simple strscpy() implementation", " - bcachefs: avoid truncating fiemap extent length", " - gpio: rockchip: change the GPIO version judgment logic", " - gpio: rockchip: teardown bugs and resource leaks", " - gpio: rockchip: fix generic IRQ chip leak on remove", " - NFSv4/flexfiles: Remove cred local variable dependency", " - iio: resolver: ad2s1210: notify trigger and clear state on fault read", " error", " - iio: temperature: Build mlx90635 with CONFIG_MLX90635", " - vfio: Remove device debugfs before releasing devres", " - PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000", " series", " - netpoll: fix a use-after-free on shutdown path", " - mm: shrinker: fix shrinker_info teardown race with expansion", " - NFSv4/flexfiles: Add data structure support for striped layouts", " - mm/khugepaged: write all dirty file folios when collapsing", " - platform/x86: intel-hid: Protect ACPI notify handler against recursion", " - Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled", " - Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()", " - fs/ntfs3: rename ni_readpage_cmpr into ni_read_folio_cmpr", " - ksmbd: use __GFP_RETRY_MAYFAIL", " - ksmbd: use opener credentials for ADS I/O", " - cpufreq: Make cpufreq_driver->exit() return void", " - cpufreq: qcom-cpufreq-hw: Fix possible double free", " - nvme: target: rdma: fix ndev refcount leak on queue connect", " - nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page", " - crypto: qat - keep VFs enabled during reset", " - crypto: qat - notify fatal error before AER reset preparation", " - crypto: qat - protect service table iterations with service_lock", " - selftests/mm: pagemap_ioctl: use the correct page size for", " transact_test()", " - iommufd: Set upper bounds on cache invalidation entry_num and entry_len", " - iommu/amd: Don't split flush for amd_iommu_domain_flush_all()", " - dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning", " - i2c: core: fix adapter probe deferral loop", " - xfs: fix null pointer dereference in tracepoint", " - xfs: don't wrap around quota ids in dqiterate", " - xfs: clamp timestamp nanoseconds correctly", " - xfs: don't zap bmbt forks if they are MAXLEVELS tall", " - iommu/vt-d: Clear Present bit before tearing down context entry", " - iommu: Pass old domain to set_dev_pasid op", " - iommu/vt-d: Cleanup intel_context_flush_present()", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " - vsock/virtio: bind uarg before filling zerocopy skb", " - iommu/amd: Use maximum Event log buffer size when SNP is enabled on", " Family 0x19", " - iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family", " 0x19", " - net: dropreason: Gather SOCKET_ drop reasons.", " - af_unix: Set drop reason in unix_release_sock().", " - af_unix: Set drop reason in manage_oob().", " - af_unix: Set drop reason in unix_stream_read_skb().", " - af_unix/scm: fix whitespace errors", " - af_unix: Don't hold unix_state_lock() in __unix_dgram_recvmsg().", " - af_unix: Don't check SOCK_DEAD in unix_stream_read_skb().", " - af_unix: Don't use skb_recv_datagram() in unix_stream_read_skb().", " - af_unix: Drop all SCM attributes for SOCKMAP.", " - time/jiffies: Change register_refined_jiffies() to void __init", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - media: uvcvideo: Do not add clock samples with small sof delta", " - serial: max310x: replace bare use of 'unsigned' with 'unsigned int'", " (checkpatch)", " - serial: max310x: implement gpio_chip::get_direction()", " - drm/gpuvm: Do not prepare NULL objects", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - soc: xilinx: Shutdown and free rx mailbox channel", " - crypto: qat - fix heartbeat error injection", " - memory: tegra: Wire up system sleep PM ops", " - drm/gpuvm: take refcount on DRM device", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - RDMA/hns: Initialize seqfile before creating file", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - RDMA/hns: Fix log flood after cmd_mbox failure", " - net: introduce page_frag_cache_drain()", " - nvmet-tcp: fix page fragment cache leak in error path", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - driver core: Use system_percpu_wq instead of system_wq", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - x86/cpu/amd: Provide a separate accessor for Node ID", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - netfilter: nfnetlink_cthelper: use {READ,WRITE}_ONCE for accessing", " helper flags", " - netfilter: synproxy: drop packets if timestamp adjustment fails", " - netfilter: synproxy: adjust duplicate timestamp options", " - netfilter: synproxy: fix unaligned memory access in timestamp adjustment", " - RDMA/siw: Fix endpoint/socket association handling", " - riscv: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - virtio_console: read size from config space during device init", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - net: dsa: qca8k: fix led devicename when using external mdio bus", " - ALSA: seq: Drop superfluous filter argument of get_event_dest_client()", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - dpll: add reference-sync netlink attribute", " - dpll: move xa_erase() call in to match dpll_pin_alloc() error path order", " - dpll: add reference sync get/set", " - dpll: Allow associating dpll pin with a firmware node", " - dpll: Add notifier chain for dpll events", " - dpll: Support dynamic pin index allocation", " - dpll: Enhance and consolidate reference counting logic", " - dpll: fix stale iteration in dpll_pin_on_pin_unregister()", " - dpll: send delete notification before unregister in on-pin rollback", " - dpll: emit per-dpll delete notifications in dpll_pin_on_pin_unregister()", " - dpll: guard sync-pair removal on full pin unregister", " - dpll: balance create/delete notifications in __dpll_pin_(un)register", " - landlock: Fix unmarked concurrent access to socket family", " - selftests/bpf: Fix typo in verify_umulti_link_info", " - udf: fix nls leak on udf_fill_super() failure", " - mfd: rsmu: Fix page register setup", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: split ep_insert() into alloc + register stages", " - eventpoll: extract ep_deliver_event() from ep_send_events()", " - eventpoll: wrap EP_UNACTIVE_PTR in typed sentinel helpers", " - eventpoll: rename epi->next and txlist for clarity", " - eventpoll: Fix epoll_wait() report false negative", " - gpiolib: acpi: Only trigger ActiveBoth interrupts on boot", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - PCI: meson: Add missing remove callback", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - workqueue: Add new WQ_PERCPU flag", " - i3c: master: add WQ_PERCPU to alloc_workqueue users", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - xfrm: Fix xfrm state cache insertion race", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - netfilter: ipset: make sure gc is properly stopped", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: hugetlb_reparenting_test: do not unmount", " - selftests/mm: save and restore nr_hugepages value", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - ipv6: annotate data-races around cnf.forwarding", " - ipv6/addrconf: annotate data-races around devconf fields (II)", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_info", " - ice: dpll: fix memory leak in ice_dpll_init_info error paths", " - net: bnxt: use ethtool string helpers", " - eth: bnxt: gather and report HW-GRO stats", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - ipv6: Add __in6_dev_get_rtnl_net().", " - octeontx2-af: Validate NIX maximum LFs correctly", " - udp_tunnel: remove rtnl_lock dependency", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - net: hisilicon: hns3: use ethtool string helpers", " - net: hns3: use string choices helper", " - net: hns3: use hns3_get_ae_dev() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: use hns3_get_ops() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: clear hns alarm: comparison of integer expressions of", " different signedness", " - net: hns3: unify copper port ksettings configuration path", " - net: hns3: refactor MAC autoneg and speed configuration", " - net: hns3: fix permanent link down deadlock after reset", " - net: hns3: differentiate autoneg default values between copper and fiber", " - rtnetlink: Add per-netns RTNL.", " - [Config] Set CONFIG_DEBUG_NET_SMALL_RTNL=n", " - rtnetlink: Add assertion helpers for per-netns RTNL.", " - rtnetlink: Define rtnl_net_trylock().", " - ipv6: Convert net.ipv6.conf.${DEV}.XXX sysctl to per-netns RTNL.", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Make /afs/. as well as /afs/ mountpoints", " - afs: Add rootcell checks", " - afs: Make /afs/@cell and /afs/.@cell symlinks", " - afs: Fix afs_atcell_get_link() to handle RCU pathwalk", " - afs: Remove the \"autocell\" mount option", " - afs: Change dynroot to create contents on demand", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - ovl: fix comment about locking order", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - afs: Convert comma to semicolon", " - afs: Fix double netfs initialisation in afs_root_iget()", " - drm/xe: Add warn when level can not be zero.", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - HID: bpf: Fix hid_bpf_get_data() range check", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - genirq/generic_chip: Introduce irq_domain_{alloc,remove}_generic_chips()", " - gpio: mvebu: free generic chips on unbind", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " - drm/xe: remove duplicate include", " - LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()", " - LoongArch: KVM: Check the return values for put_user()", " - LoongArch: KVM: Fix FPU register width with user access API", " - LoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr()", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - fbdev: efifb: fix memory leak in efifb_probe()", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - batman-adv: mcast: avoid OOB read of num_dests header", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()", " - fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry()", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - taskstats: retain dead thread stats in TGID queries", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - NFS: Charge unstable writes by request size, not folio size", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: make error counter atomic", " - accel/ivpu: Reject firmware log with size smaller than header", " - firmware_loader: introduce __free() cleanup hanler", " - Input: ims-pcu - fix firmware leak in async update", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - gpio: tegra: do not call pinctrl for GPIO direction", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - s390: Revert support for DCACHE_WORD_ACCESS", " - [Config] Set CONFIG_DCACHE_WORD_ACCESS=- for s390x", " - selftests: net: make busywait timeout clock portable", " - ata: libata: Use QUIRK instead of HORKAGE", " - ata: libata-core: Skip HPA resize for locked drives", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - ALSA: hda/cs35l41: Fix firmware load work teardown", " - io_uring/rw: ensure reissue path is correctly handled for IOPOLL", " - io_uring/rw: preserve partial result for iopoll", " - Bluetooth: L2CAP: Fix not tracking outstanding TX ident", " - mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless", " host", " - ksmbd_vfs_rename(): vfs_path_parent_lookup() accepts ERR_PTR() as name", " - vfs: make LAST_XXX private to fs/namei.c", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " - HID: pidff: Fix missing blank lines after declarations", " - HID: pidff: Add missing spaces", " - HID: pidff: Rework pidff_upload_effect", " - HID: pidff: Use correct effect type in effect update", " - bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()", " - USB: iowarrior: fix use-after-free on disconnect race", " - crypto: atmel-sha204a - fail on hwrng registration error in probe path", " - btrfs: concentrate the error handling of submit_one_sector()", " - btrfs: remove folio parameter from ordered io related functions", " - btrfs: remove the COW fixup mechanism", " - slab: Introduce kmalloc_obj() and family", " - slab: Introduce kmalloc_flex() and family", " - add default_gfp() helper macro and use it in the new *alloc_obj()", " helpers", " - default_gfp(): avoid using the \"newfangled\" __VA_OPT__ trick", " - slab: recognize @GFP parameter as optional in kernel-doc", " - fscrypt: Fix key setup in edge case with multiple data unit sizes", " - fscrypt: Replace mk_users keyring with simple list", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is", " uninitialized", " - rtnetlink: Make per-netns RTNL dereference helpers to macro.", " - afs: Fix afs_atcell_get_link() to check if ws_cell is unset first", " - afs: Fix afs_dynroot_readdir() to not use the RCU read lock", " - udp_tunnel: fix deadlock in udp_tunnel_nic_set_port_priv()", " - i40e: drop udp_tunnel_get_rx_info() call from i40e_open()", " - ice: drop udp_tunnel_get_rx_info() call from ndo_open()", " - Bluetooth: L2CAP: Fix regressions caused by reusing ident", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " - perf: Reject exited events as group leaders", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - proc: Fix broken error paths for namespace links", " - Upstream stable to v6.6.145, v6.12.96, v6.12.97", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2026-53365", " - vsock/virtio: fix zerocopy completion for multi-skb sends", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two", " - x86/mm: Fix check/use ordering in switch_mm_irqs_off()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192)", " - debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING", " - debugobjects: Use LD_WAIT_CONFIG instead of LD_WAIT_SLEEP", " - debugobjects: Dont call fill_pool() in early boot hardirq context", " - ARM: group is_permission_fault() with is_translation_fault()", " - ARM: allow __do_kernel_fault() to report execution of memory faults", " - ARM: fix branch predictor hardening", " - RDMA/bnxt_re: zero shared page before exposing to userspace", " - selftests/bpf: Add test to ensure kprobe_multi is not sleepable", " - bpf: Remove mark_precise_scalar_ids()", " - selftests/bpf: Tests for per-insn sync_linked_regs() precision tracking", " - selftests/bpf: Update comments find_equal_scalars->sync_linked_regs", " - hv: utils: handle and propagate errors in kvp_register", " - Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs", " - phonet: Pass ifindex to fill_addr().", " - phonet: Pass net and ifindex to phonet_address_notify().", " - scripts/sorttable: Remove unused macro defines", " - scripts/sorttable: Remove unused write functions", " - scripts/sorttable: Remove unneeded Elf_Rel", " - scripts/sorttable: Have the ORC code use the _r() functions to read", " - scripts/sorttable: Make compare_extable() into two functions", " - scripts/sorttable: Convert Elf_Ehdr to union", " - scripts/sorttable: Replace Elf_Shdr Macro with a union", " - scripts/sorttable: Convert Elf_Sym MACRO over to a union", " - scripts/sorttable: Add helper functions for Elf_Ehdr", " - scripts/sorttable: Add helper functions for Elf_Shdr", " - scripts/sorttable: Add helper functions for Elf_Sym", " - scripts/sorttable: Use uint64_t for mcount sorting", " - scripts/sorttable: Move code from sorttable.h into sorttable.c", " - scripts/sorttable: Get start/stop_mcount_loc from ELF file directly", " - scripts/sorttable: Use a structure of function pointers for elf helpers", " - arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64", " - [Config] Set configs to sort mcount_loc at boot for arm64", " - scripts/sorttable: Have mcount rela sort use direct values", " - scripts/sorttable: Always use an array for the mcount_loc sorting", " - scripts/sorttable: Zero out weak functions in mcount_loc table", " - ftrace: Update the mcount_loc check of skipped entries", " - ftrace: Have ftrace pages output reflect freed pages", " - ftrace: Do not over-allocate ftrace memory", " - ftrace: Test mcount_loc addr before calling ftrace_call_addr()", " - ftrace: Check against is_kernel_text() instead of kaslr_offset()", " - scripts/sorttable: Use normal sort if theres no relocs in the mcount", " section", " - scripts/sorttable: Allow matches to functions before function entry", " - scripts/sorttable: Fix endianness handling in build-time mcount sort", " - file: add fput() cleanup helper", " - eventpoll: use hlist_is_singular_node() in __ep_remove()", " - Revert \"ptp: add testptp mask test\"", " - Bluetooth: btmtk: validate WMT event SKB length before struct access", " - Bluetooth: btmtk: accept too short WMT FUNC_CTRL events", " - batman-adv: tp_meter: keep unacked list in ascending ordered", " - batman-adv: tp_meter: initialize dup_acks explicitly", " - batman-adv: tp_meter: initialize dec_cwnd explicitly", " - batman-adv: tp_meter: avoid window underflow", " - batman-adv: tp_meter: fix fast recovery precondition", " - batman-adv: tp_meter: handle seqno wrap-around for fast recovery", " detection", " - batman-adv: tp_meter: add only finished tp_vars to lists", " - batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE", " - batman-adv: prevent ELP transmission interval underflow", " - batman-adv: tp_meter: initialize last_recv_time during init", " - batman-adv: ensure bcast is writable before modifying TTL", " - batman-adv: fix (m|b)cast csum after decrementing TTL", " - batman-adv: frag: ensure fragment is writable before modifying TTL", " - batman-adv: frag: avoid underflow of TTL", " - batman-adv: tp_meter: annotate last_recv_time access with", " READ/WRITE_ONCE", " - batman-adv: tp_meter: prevent parallel modifications of last_recv", " - batman-adv: tp_meter: handle overlapping packets", " - batman-adv: tt: don't merge change entries with different VIDs", " - batman-adv: tt: track roam count per VID", " - batman-adv: dat: prevent false sharing between VLANs", " - batman-adv: tvlv: enforce 2-byte alignment", " - batman-adv: tvlv: avoid race of cifsnotfound handler state", " - inet: add indirect call wrapper for getfrag() calls", " - err.h: use __always_inline on all error pointer helpers", " - wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S", " - wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor", " - wifi: rtw88: increase TX report timeout to fix race condition", " - wifi: iwlwifi: mvm: fix race condition in PTP removal", " - f2fs: fix to round down start offset of fallocate for pin file", " - f2fs: keep atomic write retry from zeroing original data", " - MIPS: DEC: Prevent initial console buffer from landing in XKPHYS", " - fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode", " - nfsd: check get_user() return when reading princhashlen", " - NFS: Prevent resource leak in nfs_alloc_server()", " - serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero", " - wifi: mt76: mt7921: avoid undesired changes of the preset regulatory", " domain", " - ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()", " - xfs: fix error returns in CoW fork repair", " - locking/mutex: Remove wakeups from under mutex::wait_lock", " - net: ipv6: Make udp_tunnel6_xmit_skb() void", " - Revert \"PCI: qcom: Advertise Hotplug Slot Capability with no Command", " Completion support\"", " - KVM: SEV: Ignore MMIO requests of length '0'", " - mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program", " - mtd: spi-nor: macronix: add support for mx66{l2, u1}g45g", " - LoongArch: Report dying CPU to RCU in stop_this_cpu()", " - MIPS: smp: report dying CPU to RCU in stop_this_cpu()", " - locking: rtmutex: Fix wake_q logic in task_blocks_on_rt_mutex", " - bonding: annotate data-races arcound churn variables", " - Upstream stable to v6.6.144, v6.12.95", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53389", " - net/tcp-ao: fix use-after-free of key in del_async path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53393", " - nfsd: reset write verifier on deferred writeback errors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53400", " - i2c: core: fix adapter registration race", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63806", " - KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with", " get_unaligned()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63940", " - KVM: SEV: Ignore Port I/O requests of length '0'", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53387", " - iio: light: veml6075: add bounds check to veml6075_it_ms index", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53070", " - sctp: disable BH before calling udp_tunnel_xmit_skb()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43216", " - net: Drop the lock in skb_may_tx_timestamp()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64244", " - drivers/base/memory: set mem->altmap after successful device", " registration", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53384", " - serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53390", " - ksmbd: fix out-of-bounds read in smb_check_perm_dacl()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53391", " - NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53397", " - nfsd: fix posix_acl leak on SETACL decode failure", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64245", " - fbdev: modedb: fix a possible UAF in fb_find_mode()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53403", " - fbdev: Fix fb_new_modelist to prevent null-ptr-deref in", " fb_videomode_to_var", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64246", " - power: reset: linkstation-poweroff: fix use-after-free in the", " linkstation_poweroff_init()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63794", " - KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64247", " - KVM: x86: hyper-v: Bound the bank index when querying sparse banks", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63795", " - 9p: avoid putting oldfid in p9_client_walk() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63796", " - ocfs2: reject oversized group bitmap descriptors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63797", " - rpmsg: char: Fix use-after-free on probe error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64249", " - fpga: region: fix use-after-free in child_regions_with_firmware()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63798", " - irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup", " on remove", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63801", " - tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63802", " - blk-cgroup: fix UAF in __blkcg_rstat_flush()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63803", " - hdlc_ppp: sync per-proto timers before freeing hdlc state", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63804", " - gfs2: fix use-after-free in gfs2_qd_dealloc", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63809", " - bpf: use kvfree() for replaced sysctl write buffer", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63812", " - f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63814", " - f2fs: validate ACL entry sizes in f2fs_acl_from_disk()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63817", " - f2fs: validate compress cache inode only when enabled", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63821", " - wifi: rtw88: usb: fix memory leaks on USB write failures", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63822", " - wifi: ath11k: fix warning when unbinding", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63823", " - keys: Pin request_key_auth payload in instantiate paths", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63824", " - KEYS: fix overflow in keyctl_pkey_params_get_2()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63826", " - fbdev: fix use-after-free in store_modes()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64254", " - NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG", " share BAR", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63827", " - apparmor: fix use-after-free in rawdata dedup loop", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63828", " - apparmor: mediate the implicit connect of TCP fast open sendmsg", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63830", " - net: skmsg: preserve sg.copy across SG transforms", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63831", " - mac802154: llsec: add skb_cow_data() before in-place crypto", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53361", " - af_unix: Set gc_in_progress to true in unix_gc().", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63833", " - ntfs3: reject direct userspace writes to reserved $LX* xattrs", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53366", " - ipv4: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53362", " - ipv6: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63834", " - batman-adv: tp_meter: restrict number of unacked list entries", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63835", " - batman-adv: v: prevent OGM aggregation on disabled hardif", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63836", " - batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63807", " - KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping", " level", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53381", " - virtiofs: fix UAF on submount umount", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53382", " - media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53383", " - ksmbd: reject non-VALID session in compound request branch", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53385", " - vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent", " vcs_write", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53388", " - fuse: re-lock request before replacing page cache folio", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53157", " - net: phonet: free phonet_device after RCU grace period", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53163", " - locking/rtmutex: Skip remove_waiter() when waiter is not enqueued", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2025-23131", " - dlm: prevent NPD when writing a positive value to event_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-46252", " - regulator: core: fix locking in regulator_resolve_supply() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52928", " - af_unix: Reject SIOCATMARK on non-stream sockets", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43010", " - bpf: Reject sleepable kprobe_multi programs at attach time", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53325", " - agp/amd64: Fix broken error propagation in agp_amd64_probe()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64188", " - net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64191", " - i2c: stub: Reject I2C block transfers with invalid length", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53327", " - debugobjects: Do not fill_pool() if pi_blocked_on", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52909", " - ip6_vti: set netns_immutable on the fallback device.", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53167", " - fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios", "" ], "package": "linux", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 11:03:24 +0200" }, { "cves": [ { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-146.146 -proposed tracker (LP: #2166353)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", "", " * Bluetooth fails to initialize due to a kernel NULL pointer error", " (LP: #2165873)", " - Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c", "", " * Dell Precision fails to shutdown when HDMI display is connected (22.04", " HWE) (LP: #2164507)", " - drm/i915/vbt: Add fields dedicated_external and dyn_port_over_tc", " - drm/i915/display: Handle dedicated external ports in", " intel_encoder_is_tc()", "", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", "", " * [SRU] HPE: Fix for UBSAN array-index-out-of-bounds (LP: #2161004)", " - x86/platform/uv: Fix UBSAN array-index-out-of-bounds", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough", " (LP: #2089306)", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Reboot machine with ext4 configured to data=journal could dump spurious", " call trace (LP: #2164716)", " - ext4: clear stale xarray tags on folios skipped during writeback", "", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", "", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796)", " - netfilter: bitwise: rename some boolean operation functions", " - netfilter: bitwise: add support for doing AND, OR and XOR directly", " - drm/fbdev-helper: Set and clear VGA switcheroo client from fb_info", " - arm64: io: Rename ioremap_prot() to __ioremap_prot()", " - Disable -Wattribute-alias for clang-23 and newer", " - netfilter: xt_NFQUEUE: prefer raw_smp_processor_id", " - drm/imx: Fix three kernel-doc warnings in dcss-scaler.c", " - pcnet32: stop holding device spin lock during napi_complete_done", " - net: Annotate sk->sk_write_space() for UDP SOCKMAP.", " - net: lan743x: permit VLAN-tagged packets up to configured MTU", " - net: fec: fix pinctrl default state restore order on resume", " - Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame()", " extension handling", " - Bluetooth: MGMT: Fix backward compatibility with userspace", " - ptp: vclock: Switch from RCU to SRCU", " - octeontx2-af: npc: Fix CPT channel mask in npc_install_flow", " - vxlan: vnifilter: send notification on VNI add", " - vxlan: vnifilter: fix spurious notification on VNI update", " - ipmi: Fix rcu_read_unlock to srcu_read_unlock in handle_read_event_rsp", " - time: Fix off-by-one in settimeofday() usec validation", " - tools/rv: Fix cleanup after failed trace setup", " - arm64: tlb: Allow XZR argument to TLBI ops", " - iomap: don't revert iov_iter on partially completed buffered writes", " - net/mlx4: avoid GCC 10 __bad_copy_from() false positive", " - r8152: handle the return value of usb_reset_device()", " - rds: mark snapshot pages dirty in rds_info_getsockopt()", " - net: mvpp2: Add metadata support for xdp mode", " - net: mvpp2: build skb from XDP-adjusted data on XDP_PASS", " - clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time", " - tracing/probes: Point the error offset correctly for eprobe argument", " error", " - mmc: litex_mmc: Use DIV_ROUND_UP for more accurate clock calculation", " - USB: serial: option: add usb-id for Dell Wireless DW5826e-m", " - ALSA: timer: Fix UAF at snd_timer_user_params()", " - drm/amd/display: Reject gpio_bitshift >= 32 in", " bios_parser_get_gpio_pin_info()", " - mm/damon/ops-common: call folio_test_lru() after folio_get()", " - ARM: socfpga: Fix OF node refcount leak in SMP setup", " - ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O", " - mptcp: fix retransmission loop when csum is enabled", " - mptcp: sockopt: check timestamping ret value", " - selftests: mptcp: add test for extra_subflows underflow on userspace PM", " - ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write", " - inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush", " - pidfd: refuse access to tasks that have started exiting harder", " - i2c: stm32f7: fix timing computation ignoring i2c-analog-filter", " - i2c: tegra: Fix NOIRQ suspend/resume", " - Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)", " - Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard", " - net/mlx5: Reorder completion before putting command entry in", " cmd_work_handler", " - net: mv643xx: fix OF node refcount", " - octeontx2-af: fix memory leak in rvu_setup_hw_resources()", " - mmc: core: Fix host controller programming for fixed driver type", " - mmc: litex_mmc: Set mandatory idle clocks before CMD0", " - mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC", " - mmc: sdhci: add signal voltage switch in sdhci_resume_host", " - slimbus: qcom-ngd-ctrl: fix OF node refcount", " - drm/amdgpu: restart the CS if some parts of the VM are still invalidated", " - fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling", " - driver core: reject devices with unregistered buses", " - mm/hugetlb: avoid false positive lockdep assertion", " - soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get()", " - ipmi:ssif: Remove unnecessary indention", " - ipmi:ssif: NULL thread on error", " - selftests: mptcp: drop nanoseconds width specifier", " - tty: serial: samsung: use u32 for register interactions", " - RDMA/umem: fix kernel-doc warnings", " - RDMA: Move DMA block iterator logic into dedicated files", " - arm64: cputype: Add NVIDIA Olympus definitions", " - arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU", " - mptcp: add-addr: always drop other suboptions", " - mptcp: fix missing wakeups in edge scenarios", " - Revert \"selftest/ptp: update ptp selftest to exercise the gettimex", " options\"", " - ARM: fix hash_name() fault", " - wifi: remove zero-length arrays", " - soc: qcom: ice: Return -ENODEV if the ICE platform device is not found", " - Bluetooth: ISO: Fix not using bc_sid as advertisement SID", " - octeontx2-pf: Fix NDC sync operation errors", " - octeontx2-af: Fix initialization of mcam's entry2target_pffunc field", " - ima: kexec: skip IMA segment validation after kexec soft reboot", " - ima: kexec: move IMA log copy from kexec load to execute", " - gpio: zynq: fix runtime PM leak on remove", " - writeback: Avoid contention on wb->list_lock when switching inodes", " - writeback: Fix use after free in inode_switch_wbs_work_fn()", " - xfrm: hold device only for the asynchronous decryption", " - KVM: VMX: Update SVI during runtime APICv activation", " - drm/xe: fix refcount leak in xe_range_fence_insert()", " - slimbus: qcom-ngd-ctrl: Fix up platform_driver registration", " - slimbus: qcom-ngd-ctrl: Fix probe error path ordering", " - slimbus: qcom-ngd-ctrl: Initialize controller resources in controller", " - slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership", " - slimbus: qcom-ngd-ctrl: Balance pm_runtime enablement for NGD", " - drm/amd/pm: fix smu13 power limit default/cap calculation", " - drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in", " set_soft_freq_limited_range", " - drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs", " - mailbox: Fix NULL message support in mbox_send_message()", " - vsock/virtio: fix skb overhead accounting to preserve full buf_alloc", " - net: introduce EXPORT_IPV6_MOD() and EXPORT_IPV6_MOD_GPL()", " - mptcp: pm: fix extra_subflows underflow on userspace PM subflow creation", " - vsock/virtio: fix skb overhead overflow on 32-bit builds", " - Upstream stable to v6.6.143, v6.12.94", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53132", " - vsock/virtio: fix potential unbounded skb queue", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53138", " - drm/amd/display: Bound VBIOS record-chain walk loops", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53140", " - drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53332", " - slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53156", " - nvmem: core: fix use-after-free bugs in error paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53202", " - accel/ivpu: Fix signed integer truncation in IPC receive", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53205", " - accel/ivpu: Add bounds checks for firmware log indices", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53210", " - tee: shm: fix shm leak in register_shm_helper()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-31663", " - xfrm: hold dev ref until after transport_finish NF_HOOK", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53220", " - netfilter: revalidate bridge ports", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53229", " - net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46203", " - spi: cadence-quadspi: fix unclocked access on unbind", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63871", " - Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53251", " - Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63869", " - wifi: mac80211: limit injected antenna index in", " ieee80211_parse_tx_radiotap", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53261", " - devlink: Release nested relation on devlink free", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53262", " - l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses", " - arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-45850", " - ipvs: skip ipv6 extension headers for csum checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53133", " - RDMA/umem: Fix truncation for block sizes >= 4G", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52908", " - RDMA: During rereg_mr ensure that REREG_ACCESS is compatible", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53199", " - hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53134", " - netfilter: nft_fib: fix stale stack leak via the OIFNAME register", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63883", " - serial: qcom_geni: fix kfifo underflow when flush precedes DMA", " completion IRQ", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64528", " - tty: serial: samsung: Remove redundant port lock acquisition in rx", " helpers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53329", " - drm/amd/display: Use krealloc_array() in dal_vector_reserve()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53135", " - drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53136", " - drm/amd/display: Clamp VBIOS HDMI retimer register count to array size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53137", " - drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53143", " - drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on", " GFX11", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53144", " - drm/amdkfd: fix NULL dereference in get_queue_ids()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53331", " - slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53146", " - thunderbolt: Limit XDomain response copy to actual frame size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53147", " - thunderbolt: Validate XDomain request packet size before type cast", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53148", " - thunderbolt: Clamp XDomain response data copy to allocation size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53149", " - thunderbolt: Bound root directory content to block size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53150", " - thunderbolt: Reject zero-length property entries in validator", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52929", " - sctp: stream: fully roll back denied add-stream state", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52917", " - sctp: diag: reject stale associations in dump_one path", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53154", " - mm/hugetlb: restore reservation on error in hugetlb folio copy paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53336", " - nvmem: layouts: onie-tlv: fix hang on unknown types", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53337", " - net: bonding: fix NULL pointer dereference in bond_do_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53158", " - misc: fastrpc: Fix NULL pointer dereference in rpmsg callback", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53159", " - misc: fastrpc: fix DMA address corruption due to find_vma misuse", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53160", " - misc: fastrpc: fix use-after-free race in fastrpc_map_create", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53161", " - misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52930", " - ipc/shm: serialize orphan cleanup with shm_nattch updates", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53339", " - i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53168", " - fuse: reject fuse_notify() pagecache ops on directories", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53177", " - bnxt_en: Fix NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53181", " - vsock/vmci: fix sk_ack_backlog leak on failed handshake", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53182", " - wifi: nl80211: reject oversized EMA RNR lists", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53183", " - mptcp: allow subflow rcv wnd to shrink", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63867", " - mptcp: close TOCTOU race while computing rcv_wnd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53343", " - ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53184", " - udp: clear skb->dev before running a sockmap verdict", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53185", " - zram: fix use-after-free in zram_bvec_write_partial()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53190", " - drm/virtio: fix dma_fence refcount leak on error in", " virtio_gpu_dma_fence_wait()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53194", " - USB: serial: kl5kusb105: fix bulk-out buffer overflow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53195", " - USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53196", " - USB: serial: io_ti: fix heap overflow in get_manuf_info()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52935", " - xfrm: espintcp: do not reuse an in-progress partial send", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53198", " - ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53356", " - drm/i915/gem: Fix phys BO pread/pwrite with offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53345", " - KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53208", " - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53209", " - Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53213", " - drm/vc4: fix krealloc() memory leak", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53347", " - drm/virtio: Fix driver removal with disabled KMS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43116", " - netfilter: ctnetlink: ensure safe access to master conntrack", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53214", " - ipv6: Fix a potential NPD in cleanup_prefix_route()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53217", " - net: mvpp2: sync RX data at the hardware packet offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53218", " - netfilter: nft_exthdr: fix register tracking for F_PRESENT flag", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52942", " - netfilter: nf_log: validate MAC header was set before dumping it", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53219", " - netfilter: x_tables: avoid leaking percpu counter pointers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53349", " - netfilter: nf_conntrack: destroy stale expectfn expectations on", " unregister", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52939", " - net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic", " completion", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53223", " - net: guard timestamp cmsgs to real error queue skbs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53227", " - net: openvswitch: fix possible kfree_skb of ERR_PTR", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53230", " - net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52947", " - net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53232", " - net: phy: clean the sfp upstream if phy probing fails", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53236", " - tcp: restrict SO_ATTACH_FILTER to priv users", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53350", " - ASoC: wm_adsp: Fix NULL dereference when removing firmware controls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53237", " - gpio: mvebu: fix NULL pointer dereference in suspend/resume", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53238", " - netlabel: validate unlabeled address and mask attribute lengths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53239", " - xfrm: policy: fix use-after-free on inexact bin in", " xfrm_policy_bysel_ctx()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46320", " - tap: free page on error paths in tap_get_user_xdp()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53242", " - ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked", " streams", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53352", " - signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53245", " - net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63870", " - ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53249", " - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53252", " - Bluetooth: fix memory leak in error path of hci_alloc_dev()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53253", " - Bluetooth: bnep: reject short frames before parsing", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53254", " - Bluetooth: RFCOMM: validate skb length in MCC handlers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53255", " - Bluetooth: MGMT: validate advertising TLV before type checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53256", " - Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63868", " - net: garp: fix unsigned integer underflow in garp_pdu_parse_attr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53353", " - hsr: Remove WARN_ONCE() in hsr_addr_is_self().", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53263", " - 6lowpan: fix off-by-one in multicast context address compression", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53264", " - net/sched: act_api: use RCU with deferred freeing for action lifecycle", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53265", " - dm cache policy smq: check allocation under invalidate lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53266", " - netfilter: bridge: make ebt_snat ARP rewrite writable", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53267", " - netfilter: nft_ct: bail out on template ct in get eval", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53268", " - netfilter: conntrack_irc: fix possible out-of-bounds read", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53269", " - netfilter: synproxy: add mutex to guard hook reference counting", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53270", " - ipvs: clear the svc scheduler ptr early on edit", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53273", " - tee: optee: prevent use-after-free when the client exits before the", " supplicant", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53274", " - net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53275", " - ipv6: mcast: Fix use-after-free when processing MLD queries", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52948", " - i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63898", " - USB: serial: mct_u232: fix memory corruption with small endpoint", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52910", " - bpf: Free reuseport cBPF prog after RCU grace period.", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43311", " - soc/tegra: pmc: Fix unsafe generic_handle_irq() call", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43240", " - x86/kexec: add a sanity check on previous kernel's ima kexec buffer", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-23346", " - arm64: io: Extract user memory type in ioremap_prot()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52944", " - ksmbd: fix FSCTL permission bypass by adding a permission check for", " FSCTL_SET_SPARSE", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64006", " - netfilter: nf_tables: fix dst corruption in same register operation", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547)", " - Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size", " - drm/v3d: Fix use-after-free of CPU job query arrays on error path", " - drm/v3d: Release indirect CSD GEM reference on CPU job free", " - xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit", " - net/sched: sch_sfb: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - bcache: fix uninitialized closure object", " - nfc: llcp: Fix use-after-free in llcp_sock_release()", " - nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()", " - xfrm: Check for underflow in xfrm_state_mtu", " - nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems", " - kunit: fix use-after-free in debugfs when using kunit.filter", " - netfilter: xt_cpu: prefer raw_smp_processor_id", " - vsock: keep poll shutdown state consistent", " - net: netlink: fix sending unassigned nsid after assigned one", " - net: netlink: don't set nsid on local notifications", " - net/smc: Do not re-initialize smc hashtables", " - net/iucv: fix locking in .getsockopt", " - scsi: core: Run queues for all non-SDEV_DEL devices from", " scsi_run_host_queues", " - ipv4: free net->ipv4.sysctl_local_reserved_ports after", " unregister_net_sysctl_table()", " - ALSA: pcm: oss: Fix setup list UAF on proc write error", " - ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors", " - gpio: mxc: fix irq_high handling", " - ethtool: rss: fix hkey leak when indir_size is 0", " - ASoC: codecs: simple-mux: Fix enum control bounds check", " - Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()", " - bonding: refuse to enslave CAN devices", " - ethtool: eeprom: add missing ethnl_ops_begin() / _complete() during", " fallback", " - ethtool: eeprom: add more safeties to EEPROM Netlink fallback", " - net/sched: Revert \"net/sched: Restrict conditions for adding duplicating", " netems to qdisc tree\"", " - net/handshake: Use spin_lock_bh for hn_lock", " - nvme-tcp: store negative errno in queue->tls_err", " - net/handshake: Pass negative errno through handshake_complete()", " - Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success", " - Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp", " - Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close", " - gpio: rockchip: convert bank->clk to devm_clk_get_enabled()", " - net: mana: Add NULL guards in teardown path to prevent panic on attach", " failure", " - sctp: fix race between sctp_wait_for_connect and peeloff", " - ipv6: fix possible infinite loop in rt6_fill_node()", " - ipv6: fix possible infinite loop in fib6_select_path()", " - net: skbuff: fix pskb_carve leaking zcopy pages", " - perf: Fix dangling cgroup pointer in cpuctx", " - batman-adv: tvlv: abort OGM send on tvlv append failure", " - batman-adv: tt: reject oversized local TVLV buffers", " - batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface", " - batman-adv: iv: recover OGM scheduling after forward packet error", " - batman-adv: tp_meter: avoid role confusion in tp_list", " - batman-adv: tp_meter: directly shut down timer on cleanup", " - batman-adv: tt: avoid empty VLAN responses", " - batman-adv: bla: avoid double decrement of bla.num_requests", " - media: rc: fix race between unregister and urb/irq callbacks", " - media: rc: ttusbir: fix inverted error logic", " - inet: frags: add inet_frag_queue_flush()", " - HID: core: Add printk_ratelimited variants to hid_warn() etc", " - drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register", " - drm/i915/psr: Read Intel DPCD workaround register", " - drm/dp: Add eDP 1.5 bit definition", " - drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used", " - phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X", " - batman-adv: tt: prevent TVLV entry number overflow", " - iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer", " - usb: typec: ucsi: ccg: reject firmware images without a ':' record", " header", " - usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload", " VDO", " - usb: typec: altmodes/displayport: validate count before reading Status", " Update VDO", " - usb: typec: wcove: don't write past struct pd_message in", " wcove_read_rx_buffer()", " - usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT", " - usb: typec: ucsi: validate connector number in ucsi_connector_change()", " - USB: serial: safe_serial: fix memory corruption with small endpoint", " - media: rc: igorplugusb: fix control request setup packet", " - Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free()", " - HID: quirks: Add ALWAYS_POLL quirk for SIGMACHIP USB mouse", " - Bluetooth: btusb: Allow firmware re-download when version matches", " - hpfs: fix a crash if hpfs_map_dnode_bitmap fails", " - auxdisplay: line-display: fix OOB read on zero-length message_store()", " - Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn", " - Bluetooth: HIDP: fix missing length checks in hidp_input_report()", " - Bluetooth: ISO: fix UAF in iso_recv_frame", " - Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock", " - Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync", " - Input: xpad - fix out-of-bounds access for Share button", " - parport: Fix race between port and client registration", " - USB: cdc-acm: Fix bit overlap and move quirk definitions to header", " - KVM: arm64: PMU: Preserve AArch32 counter low bits", " - KVM: SVM: Flush the current TLB when transitioning from xAVIC => x2AVIC", " - iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux", " - iio: adc: npcm: fix unbalanced clk_disable_unprepare()", " - iio: dac: max5821: fix return value check in powerdown sync", " - iio: dac: ad5686: fix input raw value check", " - iio: dac: ad5686: acquire lock when doing powerdown control", " - iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw", " - iio: gyro: itg3200: fix i2c read into the wrong stack location", " - iio: gyro: adis16260: fix division by zero in write_raw", " - iio: ssp_sensors: cancel delayed work_refresh on remove", " - iio: temperature: tsys01: fix broken PROM checksum validation", " - iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL", " - iio: light: cm3323: fix reg_conf not being initialized correctly", " - iio: buffer: hw-consumer: fix use-after-free in error path", " - USB: serial: omninet: fix memory corruption with small endpoint", " - usb: cdns3: gadget: fix request skipping after clearing halt", " - usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy", " acquisition failure", " - usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently", " leaks the runtime PM usage counter across bind/unbind cycles", " - usb: dwc2: Fix use after free in debug code", " - Input: elan_i2c - validate firmware size before use", " - wireguard: send: append trailer after expanding head", " - bpf: sockmap: fix tail fragment offset in bpf_msg_push_data", " - macsec: fix replay protection at XPN lower-PN wrap", " - ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params", " - ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().", " - ipv6: validate extension header length before copying to cmsg", " - xfrm: input: hold netns during deferred transport reinjection", " - ip6: vti: Use ip6_tnl.net in vti6_changelink().", " - HID: wacom: Fix OOB write in wacom_hid_set_device_mode()", " - iommu, debugobjects: avoid gcc-16.1 section mismatch warnings", " - nfc: hci: fix out-of-bounds read in HCP header parsing", " - xfrm: route MIGRATE notifications to caller's netns", " - xfrm: ah: use skb_to_full_sk in async output callbacks", " - ALSA: scarlett2: Fix 2i2 Gen 4 direct monitor gain on firmware 2417", " - netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without", " direction check", " - ASoC: qcom: q6asm-dai: close stream only when running", " - ASoC: qcom: q6asm-dai: do not set stream state in event and trigger", " callbacks", " - Input: xpad - add \"Nova 2 Lite\" from GameSir", " - Input: xpad - add support for ASUS ROG RAIKIRI II", " - ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops", " - Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem", " - Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490", " - comedi: comedi_test: fix check for valid scan_begin_src in", " waveform_ai_cmdtest()", " - comedi: comedi_test: Fix limiting of convert_arg in", " waveform_ai_cmdtest()", " - counter: Fix refcount leak in counter_alloc() error path", " - tty: serial: pch_uart: add check for dma_alloc_coherent()", " - usb: chipidea: core: convert ci_role_switch to local variable", " - usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval", " - USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub", " controllers", " - usb: storage: Add quirks for PNY Elite Portable SSD", " - usbip: vudc: Fix use after free bug in vudc_remove due to race condition", " - usb: usbtmc: check URB actual_length for interrupt-IN notifications", " - usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize", " - USB: serial: option: add MeiG SRM813Q", " - USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL", " - USB: serial: belkin_sa: validate interrupt status length", " - USB: serial: cypress_m8: validate interrupt packet headers", " - USB: serial: keyspan: fix missing indat transfer sanity check", " - USB: serial: mxuport: fix memory corruption with small endpoint", " - USB: serial: mct_u232: fix missing interrupt-in transfer sanity check", " - usb: gadget: uvc: hold opts->lock across XU walks in uvc_function_bind", " - usb: gadget: net2280: Fix double free in probe error path", " - usb: gadget: f_hid: fix device reference leak in hidg_alloc()", " - usb: gadget: composite: fix integer underflow in WebUSB GET_URL handling", " - usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports", " - usb: gadget: f_fs: copy only received bytes on short ep0 read", " - thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()", " - thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow", " - scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker", " - scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32", " - drm/hyperv: validate resolution_count and fix WIN8 fallback", " - drm/hyperv: validate VMBus packet size in receive callback", " - drm/i915: Fix potential UAF in TTM object purge", " - drm/amd/pm/si: Disregard vblank time when no displays are connected", " - serial: altera_jtaguart: handle uart_add_one_port() failures", " - serial: qcom-geni: fix UART_RX_PAR_EN bit position", " - serial: sh-sci: fix memory region release in error path", " - serial: zs: Fix swapped RI/DSR modem line transition counting", " - serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma", " - drm/amdkfd: fix NULL pointer bug in svm_range_set_attr", " - drm/amdkfd: fix a vulnerability of integer overflow in kfd debugger", " - drm/amdkfd: Check for pdd drm file first in CRIU restore path", " - serial: dz: Fix bootconsole message clobbering at chip reset", " - serial: dz: Fix bootconsole handover lockup", " - serial: dz: Convert to use a platform device", " - serial: zs: Fix bootconsole handover lockup", " - serial: zs: Switch to using channel reset", " - serial: zs: Convert to use a platform device", " - USB: serial: cypress_m8: fix memory corruption with small endpoint", " - USB: serial: digi_acceleport: fix memory corruption with small endpoints", " - xhci: tegra: Fix ghost USB device on dual-role port unplug", " - iommu: Skip PASID validation for devices without PASID capability", " - x86/boot: Disable stack protector for early boot code", " - rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg", " - rxrpc: Fix RESPONSE packet verification to extract skb to a linear", " buffer", " - serdev: Provide a bustype shutdown function", " - Bluetooth: hci_qca: Migrate to serdev specific shutdown function", " - Bluetooth: hci_qca: Convert timeout from jiffies to ms", " - ALSA: scarlett2: Return ENOSPC for out-of-bounds flash writes", " - ALSA: scarlett2: Allow flash writes ending at segment boundary", " - mm/memory: fix spurious warning when unmapping device-private/exclusive", " pages", " - platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery", " - net: hsr: defer node table free until after RCU readers", " - mptcp: pm: fix ADD_ADDR timer infinite retry on option space", " insufficient", " - ice: fix VF queue configuration with low MTU values", " - mptcp: cleanup fallback dummy mapping generation", " - mptcp: reset rcv wnd on disconnect", " - arm64: tlb: Flush walk cache when unsharing PMD tables", " - octeontx2-pf: avoid double free of pool->stack on AQ init failure", " - mptcp: introduce the mptcp_init_skb helper", " - mptcp: handle first subflow closing consistently", " - mptcp: do not drop partial packets", " - mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()", " - iio: chemical: scd30: Use guard(mutex) to allow early returns", " - iio: chemical: scd30: fix division by zero in write_raw", " - iio: dac: ad5686: fix ref bit initialization for single-channel parts", " - ALSA: firewire-motu: Protect register DSP event queue positions", " - usb: dwc3: xilinx: fix error handling in zynqmp init error paths", " - usb: musb: omap2430: Fix use-after-free in omap2430_probe()", " - usb: typec: ucsi: Check if power role change actually happened before", " handling", " - thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()", " - usb: typec: ucsi: Don't update power_supply on power role change if not", " connected", " - hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with", " pmbus_lock", " - hwmon: (pmbus/adm1266) serialize NVMEM blackbox read with pmbus_lock", " - hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock", " - mm: perform all memfd seal checks in a single place", " - mm/memfd: fix spelling and grammatical issues", " - memfd: deny writeable mappings when implying SEAL_WRITE", " - usb: core: Fix SuperSpeed root hub wMaxPacketSize", " - Upstream stable to v6.12.93", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43331", " - x86/kexec: Disable KCOV instrumentation after load_segments()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52943", " - net: skbuff: fix missing zerocopy reference in pskb_carve helpers", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53358", " - Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52923", " - ipc: limit next_id allocation to the valid ID range", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2025-68768", " - inet: frags: flush pending skbs in fqdir_pre_exit()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43303", " - mm/page_alloc: clear page->private in free_pages_prepare()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52934", " - batman-adv: tvlv: reject oversized TVLV packets", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52913", " - batman-adv: v: stop OGMv2 on disabled interface", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46322", " - tun: free page on build_skb failure in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46321", " - tun: free page on short-frame rejection in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52927", " - netfilter: ebtables: fix OOB read in compat_mtw_from_user", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43219", " - net: cpsw_new: Fix potential unregister of netdev that has not been", " registered yet", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-45930", " - net: mctp: ensure our nlmsg responses are initialised", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53080", " - net/sched: cls_fw: fix NULL dereference of \"old\" filters before change()", "", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Enable CONFIG_ARM64_ERRATUM_4118414", "", " * CVE-2025-10263", " - arm64: cputype: Add C1-Ultra definitions", " - arm64: cputype: Add C1-Premium definitions", "", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", "", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", "", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", "", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", "", " * CVE-2026-63886", " - scsi: target: iscsi: Validate CHAP_R length before base64 decode", "", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", "", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", "", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", "", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", "", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", "", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", "", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", "", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", "", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", "", " * CVE-2026-64000", " - net: hsr: fix potential OOB access in supervision frame handling", "", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", "", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", "", " * CVE-2026-53131", " - netfilter: require Ethernet MAC header before using eth_hdr()", "" ], "package": "linux", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:47:58 +0300" } ], "notes": "linux-tools-6.8.0-147 version '6.8.0-147.147' (source package linux version '6.8.0-147.147') was added. linux-tools-6.8.0-147 version '6.8.0-147.147' has the same source package name, linux, as removed package linux-headers-6.8.0-142. As such we can use the source package version of the removed package, '6.8.0-142.142', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-tools-6.8.0-147-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-147.147 -proposed tracker (LP: #2168142)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026)", " - platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug", " - selftests/bpf: Add tests for ld_{abs,ind} failure path in subprogs", " - drm/virtio: fix deadlock in display_info_cb by removing hotplug from", " dequeue worker", " - mtd: mtdswap: remove debugfs stats file on teardown", " - seqlock: Cure some more scoped_seqlock() optimization fails", " - seqlock: Allow KASAN to fail optimizing", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/umem: Add support for creating pinned DMABUF umem with a given dma", " device", " - RDMA/umem: Introduce an option to revoke DMABUF umem", " - RDMA/umem: Add ib_umem_dmabuf_get_pinned_and_lock helper", " - RDMA/umem: Move umem dmabuf revoke logic into helper function", " - RDMA/umem: Add pinned revocable dmabuf import interface", " - RDMA/umem: Add helpers for umem dmabuf revoke lock", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - selftests/alsa: Fix memory leak in find_controls error path", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: cs42l43: Correct report for forced microphone jack", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - sched/vtime: Get rid of generic vtime_task_switch() implementation", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - can: j1939: fix lockless local-destination check", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - crypto: rsa-pkcs1pad: Don't WARN on an empty digest", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - wifi: ath11k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - wifi: ath12k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - ASoC: cs35l56: Don't use devres to unregister component", " - ASoC: cs35l56: Fix potential probe() deadlock", " - ASoC: cs35l56: Use complete_all() to signal init_completion", " - wifi: iwlwifi: mvm: validate SAR GEO response payload size", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - hwmon: (asus-ec-sensors) fix looping over banks while reading from EC", " - hwmon: (asus-ec-sensors) fix EC read intervals", " - hwmon: (asus-ec-sensors) add missed handle for ENOMEM", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - pds_core: yield the CPU while waiting for the adminq to drain", " - pds_core: order completion reads after the ownership check", " - pds_core: check for workqueue allocation failure", " - tls: device: push pending open record on splice EOF", " - selftest: af_unix: Add Kconfig file.", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - amt: make the head writable before rewriting the L2 header", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: dpaa: fix mode setting", " - iomap: correct the range of a partial dirty clear", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - net: stmmac: enable the MAC on link up for all supported speeds", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - ppp: use IFF_NO_QUEUE in virtual interfaces", " - ppp: convert to percpu netstats", " - ppp: enable TX scatter-gather", " - ppp: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: fix LAG recipe to profile association", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't", " at 0 (v2)", " - drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nxp: imx8-isi: Clean up already-initialized pipes on probe", " failure", " - media: nxp: imx8-isi: Fix missing v4l2_subdev_cleanup() in pipe init", " error path", " - media: nxp: imx8-isi: Fix scale factor calculation for hardware rounding", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vivid: add vivid_update_reduced_fps()", " - media: vpif_capture: fix OF node reference imbalance", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - LoongArch: Fix oops during single-step debugging", " - x86/boot/compressed: Disable jump tables", " - serial: sc16is7xx: implement gpio get_direction() callback", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - ice: use READ_ONCE() to access cached PHC time", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amd/display: Fix dcn32 DTB DTO update breaking live pixel rate", " sources", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - net: pcs: xpcs: fix SGMII state reading", " - bpf: drop bpf_lsm_getselfattr from hook list", " - udmabuf: Do not create malformed scatterlists", " - i2c: davinci: Unregister cpufreq notifier on probe failure", " - VFS/audit: introduce kern_path_parent() for audit", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - rxrpc: Pull out certain app callback funcs into an ops table", " - fbcon: Rename struct fbcon_ops to struct fbcon_par", " - fbcon: Use correct type for vc_resize() return value", " - rxrpc: Don't need barrier for ->tx_bottom and ->acks_hard_ack", " - rxrpc: Use irq-disabling spinlocks between app and I/O thread", " - rxrpc: Fix notification vs call-release vs recvmsg", " - rxrpc: Fix socket notification race", " - vduse: Use fixed 4KB bounce pages for non-4KB page size", " - vduse: remove unused vaddr parameter of vduse_domain_free_coherent", " - vduse: take out allocations from vduse_dev_alloc_coherent", " - octeontx2: Annotate mmio regions as __iomem", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - fbdev/efifb: Replace references to global screen_info by local pointer", " - ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable()", " - ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe()", " - ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb", " - ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - netfilter: nft_set_pipapo: use GFP_KERNEL for insertions", " - netfilter: nft_set_pipapo: move prove_locking helper around", " - netfilter: nft_set_pipapo: make pipapo_clone helper return NULL", " - netfilter: nft_set_pipapo: prepare walk function for on-demand clone", " - netfilter: nft_set_pipapo: merge deactivate helper into caller", " - netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone", " - netfilter: nft_set_pipapo: move cloning of match info to insert/removal", " path", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_tables: Remove unused nft_reduce_is_readonly()", " - netfilter: nf_tables: remove register tracking infrastructure", " - NFSD: pass nfsd_file to nfsd_iter_read()", " - sunrpc: allocate a separate bvec array for socket sends", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - dma: dw-edma: Fix build warning in dw_edma_pcie_probe()", " - dmaengine: dw-edma: Fix confusing cleanup.h syntax", " - platform/x86: dell-smbios: Move request functions for reuse", " - i2c: imx: separate atomic, dma and non-dma use case", " - nfs: remove dead code for the old swap over NFS implementation", " - ovl: use linked upper dentry in copy-up tmpfile", " - bootconfig: do not put quotes on cmdline items unless necessary", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - rxrpc: Disable IRQ, not BH, to take the lock for ->attend_link", " - netfilter: nft_quota: use atomic64_xchg for reset", " - soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE", " - wifi: cfg80211: pass net_device to .set_monitor_channel", " - wifi: cfg80211: define and use wiphy guard", " - wifi: cfg80211: derive S1G beacon TSF from S1G fields", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - smb: move some duplicate definitions to common/cifsglob.h", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - wifi: mt76: mt7925: extend mt7925_mcu_bss_he_tlv for per-link BSS", " - ovl: fix trusted xattr escape prefix matching", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - dpll: add clock quality level attribute and op", " - net/mlx5: DPLL, Add clock quality level op implementation", " - net/mlx5: Remove newline at the end of a netlink error message", " - net/mlx5: Refactor EEPROM query error handling to return status", " separately", " - octeontx2-pf: tc: fix egress ratelimiting", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm/displayid: move drm_displayid.h to drm_displayd_internal.h", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - ALSA: timer: drain a slave's callback before its master detaches it", " - ALSA: timer: don't re-enter an instance callback that is still running", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - sysctl: treewide: constify ctl_table_header::ctl_table_arg", " - ceph: fix refcount leak in ceph_readdir()", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - net: move skb_gro_receive_list from udp to core", " - net: add pskb_may_pull() to skb_gro_receive_list()", " - vsock/virtio: collapse receive queue under memory pressure", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - xfs: add an explicit owner field to xfs_da_args", " - xfs: factor out xfs_attr3_leaf_init", " - xfs: don't replace the wrong part of the cow fork", " - rxrpc: Fix CPU time starvation in I/O thread", " - ASoC: mediatek: mt8183-afe-pcm: Shorten memif_data table using macros", " - ASoC: mediatek: mt8183-afe-pcm: Support >32 bit DMA addresses", " - tcp: Decrement tcp_md5_needed static branch", " - nvmet: Introduce nvmet_req_transfer_len()", " - block: add helper add_disk_final()", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections", " - Bluetooth: hci_core: Fix not accounting for BIS/CIS/PA links separately", " - afs: Improve server refcount/active count tracing", " - afs: Make afs_lookup_cell() take a trace note", " - afs: Drop the net parameter from afs_unuse_cell()", " - rxrpc: Allow the app to store private data on peer structs", " - afs: Use the per-peer app data provided by rxrpc", " - afs: Fix afs_server ref accounting", " - afs: Simplify cell record handling", " - afs: Fix dynamic lookup to fail on cell lookup failure", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - lib/string_choices: Add str_plural() helper", " - USB: gadget: Use str_enable_disable-like helpers", " - usb: musb: omap2430: clean up probe error handling", " - net/mlx5e: Fix NULL pointer dereference in ioctl module EEPROM query", " - rxrpc: Fix locking issues with the peer record hash", " - wifi: nl80211: fix nl80211_start_radar_detection return value", " - afs: Set vllist to NULL if addr parsing fails", " - dpll: fix clock quality level reporting", " - afs: Fix delayed allocation of a cell's anonymous key", " - afs: handle CB.InitCallBackState3 requests without a server record", " - Bluetooth: hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK", " - Bluetooth: hci_conn: Fix not cleaning up Broadcaster/Broadcast Source", " - Bluetooth: hci_conn: Remove redundant memset after kzalloc", " - Bluetooth: hci_conn: Fix not cleaning up PA_LINK connections", " - Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()", " - afs: Fix uninit var in afs_alloc_anon_key()", " - Upstream stable to v6.6.148, v6.12.101", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72168", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72213", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72244", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53078", " - bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2025-40098", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_get_acpi_mute_state()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68372", " - usb: core: port: Deattach Type-C connector on component unbind", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72175", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45901", " - netfilter: nf_tables: revert commit_mutex usage in reset path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45897", " - netfilter: nft_counter: serialize reset with spinlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72015", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72017", " - net: macb: drop in-flight Tx SKBs on close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72030", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72023", " - octeontx2-pf: fix SQB pointer leak on init failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72040", " - ipmi: fix refcount leak in i_ipmi_request()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72045", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72062", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72051", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72070", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72142", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72147", " - dmaengine: dw-edma-pcie: Reject devices without driver data", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72254", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72253", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72260", " - ASoC: mediatek: mt8192: Check runtime resume during probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72305", " - VDUSE: avoid leaking information to userspace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64205", " - i2c: i801: fix hardware state machine corruption in error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64280", " - fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72146", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72124", " - can: isotp: serialize TX state transitions under so->rx_lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72125", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72115", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72117", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72116", " - can: bcm: fix stale rx/tx ops after device removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72113", " - can: bcm: add missing device refcount for CAN filter removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72114", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72119", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72118", " - can: bcm: fix CAN frame rx/tx statistics", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72121", " - can: bcm: add locking when updating filter and timer values", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53090", " - bpf: Fix ld_{abs,ind} failure path analysis in subprogs", "", " * test_vxlan_vnifiltering.sh from ubuntu_kselftests_net failed on linux-", " oem-6.8 (with ipv6 default rdst) (LP: #2071590)", " - selftests: net: use slowwait to make sure IPv6 setup finished", "", " * ubuntu_bpf failed to build in noble (error: redefinition of", " 'stack_load_preserves_const_precision') (LP: #2160493)", " - SAUCE: Revert \"selftests/bpf: validate fake register spill/fill", " precision backtracking logic\"", "", " * CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", "", " * Backport: \"mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios\"", " (LP: #2162917)", " - mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios", "", " * qrtr: ns: node limit of 64 breaks QRTR routing on large multi-node", " deployments (LP: #2165140)", " - net: qrtr: ns: Raise node count limit to 512", "", " * [UBUNTU 24.04] kernel: CPU hotplug unsupported by CPUMF (LP: #2165732)", " - s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks", "", " * CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", "", " * CVE-2025-38563", " - perf/core: Prevent VMA split of buffer mappings", "", " * CVE-2025-38565", " - perf/core: Exit early on perf_mmap() fail", "", " * CVE-2025-38187", " - drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()", "", " * CVE-2025-38069", " - PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops", "", " * CVE-2025-40014", " - objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()", "", " * CVE-2025-21985", " - drm/amd/display: Fix out-of-bound accesses", "", " * CVE-2024-56552", " - drm/xe/guc_submit: fix race around suspend_pending", "", " * CVE-2025-21687", " - vfio/platform: check the bounds of read/write syscalls", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237)", " - ext4: fix fd leak in EXT4_IOC_MOVE_EXT cross-sb validation", " - mm: refactor mm_access() to not return NULL", " - Upstream stable to v6.6.146, v6.12.98, v6.6.147, v6.12.99, v6.12.100", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237) //", " CVE-2026-64560", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995)", " - bpf, arm64: Reject out-of-range B.cond targets", " - nfsd: release layout stid on setlease failure", " - Bluetooth: btmtk: apply the common btmtk_fw_get_filename", " - Bluetooth: btmtk: Fix failed to send func ctrl for MediaTek devices.", " - Bluetooth: btmtk: Fix wait_on_bit_timeout interruption during shutdown", " - userfaultfd: gate must_wait writability check on pte_present()", " - perf: Fix dangling cgroup pointer in cpuctx backport", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error", " - device property: initialize the remaining fields of fwnode_handle in", " fwnode_init()", " - f2fs: validate orphan inode entry count", " - f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode", " - f2fs: fix potential deadlock in f2fs_balance_fs()", " - f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()", " - f2fs: fix listxattr handling of corrupted xattr entries", " - block: Avoid mounting the bdev pseudo-filesystem in userspace", " - i2c: core: fix irq domain leak on adapter registration failure", " - i2c: core: fix hang on adapter registration failure", " - i2c: core: fix NULL-deref on adapter registration failure", " - i2c: core: fix adapter debugfs creation", " - fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()", " - NFSv4/flexfiles: reject zero filehandle version count", " - locking/rtmutex: Make sure we wake anything on the wake_q when we", " release the lock->wait_lock", " - bonding: fix xfrm offload feature setup on active-backup mode", " - mm/vmscan: flush deferred TLB before freeing large folios", " - perf trace beauty fcntl: Fix build with older kernel headers", " - ACPI: CPPC: Suppress UBSAN warning caused by field misuse", " - ACPI: NFIT: core: Fix possible NULL pointer dereference", " - perf/core: Detach event groups during remove_on_exec", " - arm64: sysreg: Add layout for ID_AA64MMFR4_EL1", " - virtio_net: Support dynamic rss indirection table size", " - LoongArch: Add PIO for early access before ACPI PCI root register", " - usb: gadget: function: rndis: add length check to response query", " - usb: gadget: function: rndis: add length check for header", " - iio: accel: bmc150: clamp the device-reported FIFO frame count", " - iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error", " - iio: adc: lpc32xx: Initialize completion before requesting IRQ", " - iio: adc: ti-ads124s08: Return reset GPIO lookup errors", " - iio: chemical: scd30: Cleanup initializations and fix sign-extension bug", " - iio: event: Fix event FIFO reset race", " - iio: gyro: bmg160: bail out when bandwidth/filter is not in table", " - iio: gyro: bmg160: wait full startup time after mode change at probe", " - iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ", " - iio: imu: st_lsm6dsx: deselect shub page before reading whoami", " - iio: light: al3010: fix incorrect scale for the highest gain range", " - iio: light: gp2ap002: fix runtime PM leak on read error", " - iio: light: opt3001: fix missing state reset on timeout", " - iio: light: tsl2591: return actual error from probe IRQ failure", " - iio: light: veml6030: fix channel type when pushing events", " - iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call", " - iio: temperature: ltc2983: Fix reinit_completion() called after", " conversion start", " - ALSA: virtio: Add missing 384 kHz PCM rate mapping", " - ALSA: ymfpci: check snd_ctl_new1() return value", " - ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input", " parser", " - ALSA: cmipci: check snd_ctl_new1() return value", " - ALSA: es1938: check snd_ctl_new1() return value", " - ALSA: firewire: isight: bound the sample count to the packet payload", " - ALSA: gus: check snd_ctl_new1() return value", " - ALSA: ice1712: check snd_ctl_new1() return value", " - ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()", " - ALSA: usb-audio: avoid kobject path lookup in DualSense match", " - ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()", " - ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch", " put callbacks", " - ALSA: usb-audio: Update Babyface Pro control caches only after", " successful writes", " - ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful", " writes", " - vfio/pci: Use a private flag to prevent power state change with VFs", " - vfio/pci: Latch disable_idle_d3 per device", " - vfio/pci: Release the VGA arbiter client on register_device() failure", " - vfio/pci: Fix racy bitfields and tighten struct layout", " - vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc", " - Bluetooth: btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB", " - Bluetooth: btusb: fix use-after-free on registration failure", " - Bluetooth: btusb: fix use-after-free on marvell probe failure", " - Bluetooth: btusb: fix wakeup source leak on probe failure", " - binder: fix UAF in binder_thread_release()", " - binder: fix UAF in binder_free_transaction()", " - usb: xhci: Fix sleep in atomic context in xhci_free_streams()", " - PCI: altera: Do not dispose parent IRQ mapping", " - mm/damon/ops-common: handle extreme intervals in damon_hot_score()", " - netfilter: ipset: fix race between dump and ip_set_list resize", " - virtio-mmio: fix device release warning on module unload", " - hwrng: virtio: clamp device-reported used.len at copy_data()", " - USB: chaoskey: Fix slab-use-after-free in chaoskey_release()", " - usb: dwc3: run gadget disconnect from sleepable suspend context", " - 6lowpan: fix NHC entry use-after-free on error path", " - tipc: fix out-of-bounds read in broadcast Gap ACK blocks", " - staging: vme_user: bound slave read/write to the kern_buf size", " - smb: client: restrict implied bcc[0] exemption to responses without data", " area", " - staging: vme_user: fix location monitor leak in fake bridge", " - staging: vme_user: fix location monitor leak in tsi148 bridge", " - media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe", " - staging: media: atomisp: reduce load_primary_binaries() stack usage", " - staging: rtl8723bs: fix heap buffer overflow in", " rtw_cfg80211_set_wpa_ie()", " - staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()", " - staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop", " - staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop", " - staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and", " join_cmd_hdl()", " - staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop", " - staging: rtl8723bs: fix OOB write in HT_caps_handler()", " - crypto: amlogic - avoid double cleanup in meson_crypto_probe()", " - ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then", " SMB2_CANCEL", " - net: af_key: initialize alg_key_len for IPComp states", " - audit: Fix data races of skb_queue_len() readers on audit_queue", " - Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete", " - debugobjects: Plug race against a concurrent OOM disable", " - fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns", " - NTB: epf: Avoid calling pci_irq_vector() from hardirq context", " - io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item", " - ipv4: igmp: remove multicast group from hash table on device destruction", " - net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes", " - mfd: cros_ec: Delay dev_set_drvdata() until probe success", " - mm: shrinker: fix NULL pointer dereference in debugfs", " - netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump", " - f2fs: bound i_inline_xattr_size for non-inline-xattr inodes", " - drm/amd: Fix set but not used warnings", " - apparmor: advertise the tcp fast open fix is applied", " - nfsd: move name lookup out of nfsd4_list_rec_dir()", " - nfsd: change nfs4_client_to_reclaim() to allocate data", " - arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative", " - arm64: Fix early handling of FEAT_E2H0 not being implemented", " - KVM: arm64: Initialize HCR_EL2.E2H early", " - arm64: Revamp HCR_EL2.E2H RES1 detection", " - arm64: sysreg: Correct sign definitions for EIESB and DoubleLock", " - iio: adc: spear: Initialize completion before requesting IRQ", " - iio: imu: inv_icm42600: fix timestamp clock period by using lower value", " - ALSA: usb-audio: Roll back quirk control caches on write errors", " - usb: typec: tcpci_rt1711h: unregister TCPCI port with devres", " - gpio: eic-sprd: use raw_spinlock_t in the irq startup path", " - netfilter: ebtables: module names must be null-terminated", " - netfilter: ebtables: terminate table name before find_table_lock()", " - Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()", " - Bluetooth: bnep: pin L2CAP connection during netdev registration", " - Bluetooth: btnxpuart: Fix out-of-bounds firmware read in", " nxp_recv_fw_req_v3()", " - Bluetooth: fix UAF in bt_accept_dequeue()", " - Bluetooth: L2CAP: validate option length before reading conf opt value", " - fs/ntfs3: fsync files by syncing parent inodes", " - fs/ntfs3: zero-fill folios beyond i_valid in ntfs_read_folio()", " - fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()", " - coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer()", " - smb/client: Fix error code in smb2_aead_req_alloc()", " - ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE", " - ksmbd: add a permission check for FSCTL_SET_ZERO_DATA", " - ksmbd: serialize QUERY_DIRECTORY requests per file", " - ksmbd: require source read access for duplicate extents", " - ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock", " cancellation", " - ksmbd: add a WRITE_DAC/WRITE_OWNER check to SMB2 SET_INFO SECURITY", " - ksmbd: run set info with opener credentials", " - ksmbd: enforce FILE_READ_ATTRIBUTES on SMB_FIND_FILE_POSIX_INFORMATION", " - ksmbd: add per-handle permission check to FILE_LINK_INFORMATION", " - ksmbd: use opener credentials for delete-on-close", " - smb: client: fix query directory replay double-free", " - smb: client: fix query_info() replay double-free", " - smb: client: fix double-free in SMB2_ioctl() replay", " - smb: client: fix change notify replay double-free", " - smb: client: fix double-free in SMB2_flush() replay", " - smb: client: fix double-free in SMB2_open() replay", " - smb: client: fix double-free in SMB2_close() replay", " - smb: client: Fix next buffer leak in receive_encrypted_standard()", " - smb: client: use unaligned reads in parse_posix_ctxt()", " - smb: client: harden POSIX SID length parsing", " - smb: client: mask server-provided mode to 07777 in modefromsid", " - OPP: of: Fix potential memory leak in opp_parse_supplies()", " - firmware_loader: fix device reference leak in firmware_upload_register()", " - cpufreq: intel_pstate: Sync policy->cur during CPU offline", " - sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT", " - cpufreq: Fix hotplug-suspend race during reboot", " - cpufreq: pcc: fix use-after-free and double free in _OSC evaluation", " - posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path", " - clocksource/drivers/timer-tegra186: Fix support for multiple watchdog", " instances", " - X.509: Fix validation of ASN.1 certificate header", " - tools/mm/slabinfo: Fix trace disable logic inversion", " - tools/mm/slabinfo: fix total_objects attribute name", " - HID: wacom: stop hardware after post-start probe failures", " - HID: letsketch: fix UAF on inrange_timer at driver unbind", " - HID: lg-g15: cancel pending work on remove to fix a use-after-free", " - HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte", " reads", " - hfs/hfsplus: zero-initialize buffer in hfs_bnode_read", " - nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers", " - media: mtk-jpeg: cancel workqueue on release for supported platforms", " only", " - xfs: use null daddr for unset first bad log block", " - xfs: fix unreachable BIGTIME check in dquot flush validation", " - bpf: Reject fragmented frames in devmap", " - bpf: Restore sysctl new-value from 1 to 0", " - net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()", " - usb: cdc_acm: Add quirk for Uniden BC125AT scanner", " - usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()", " - USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub", " - usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()", " - usb: free iso schedules on failed submit", " - usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler", " - usb: gadget: udc: Fix use-after-free in gadget_match_driver", " - usb: gadget: f_printer: take kref only for successful open", " - USB: idmouse: fix use-after-free on disconnect race", " - USB: ldusb: fix use-after-free on disconnect race", " - USB: iowarrior: fix use-after-free on disconnect", " - USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD", " - USB: legousbtower: fix use-after-free on disconnect race", " - usb: sl811-hcd: disable controller wakeup on remove", " - USB: storage: include US_FL_NO_SAME in quirks mask", " - USB: misc: uss720: unregister parport on probe failure", " - usb: mtu3: unmap request DMA on queue failure", " - USB: serial: keyspan_pda: fix information leak", " - USB: serial: option: add Telit Cinterion FE990D50 compositions", " - USB: serial: digi_acceleport: fix broken rx after throttle", " - USB: serial: digi_acceleport: fix hard lockup on disconnect", " - USB: serial: digi_acceleport: fix write buffer corruption", " - USB: ulpi: fix memory leak on registration failure", " - USB: usb-storage: ene_ub6250: restore media-ready check", " - usbip: tools: support SuperSpeedPlus devices", " - usbip: vudc: fix NULL deref in vep_dequeue()", " - usb: typec: anx7411: use devm_pm_runtime_enable()", " - usb: typec: class: drop PD lookup reference", " - usb: typec: tcpm: Validate SVID index in svdm_consume_modes()", " - usb: typec: ucsi: Invert DisplayPort role assignment", " - usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt", " mode", " - usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove", " - usb: typec: ucsi: cancel pending work on system suspend", " - iio: temperature: ltc2983: Fix n_wires default bypassing rotation check", " - PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining", " - udf: validate free block extents against the partition length", " - udf: validate VAT header length against the VAT inode size", " - udf: validate sparing table length as an entry count, not a byte count", " - hwrng: jh7110 - fix refcount leak in starfive_trng_read()", " - dm-ioctl: report an error if a device has no table", " - nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace", " disks", " - btrfs: do not trim a device which is not writeable", " - partitions: aix: bound the pp_count scan to the ppe array", " - isofs: bound Rock Ridge symlink components to the SL record", " - crypto: af_alg - Remove zero-copy support from skcipher and aead", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps again", " - crypto: ecc - Fix carry overflow in vli multiplication", " - crypto: pcrypt - restore callback for non-parallel fallback", " - crypto: drbg - Fix returning success on failure in CTR_DRBG", " - crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels", " - crypto: drbg - Fix the fips_enabled priority boost", " - crypto: qat - validate RSA CRT component lengths", " - crypto: talitos - use dma_sync_single_for_cpu() before reading", " descriptor header", " - crypto: talitos - add chaining of arbitrary number of descriptor for the", " SEC1", " - crypto: talitos - move dma unmapping code in flush_channel() into a", " standalone dma_unmap_request() function", " - crypto: talitos - move dma mapping code in talitos_submit() into a", " standalone dma_map_request() function", " - crypto: talitos - move code in current_desc_hdr() into a standalone", " function", " - crypto: talitos/hash - prepare SEC1 descriptor chaining, remove", " additional descriptor", " - crypto: talitos/hash - use descriptor chaining for SEC1 instead of", " workqueue", " - crypto: talitos/hash - drop workqueue mechanism for SEC1", " - crypto: talitos/hash - rename first_desc/last_desc to", " first_request/last_request", " - crypto: talitos/hash - remove useless wrapper", " - crypto: talitos/hash - fix SEC2 64k - 1 ahash request limitation", " - arm64: fpsimd: Fix type mismatch in sme_{save,load}_state()", " - spi: fsl-lpspi: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - spi: fsl-lpspi: terminate the RX channel on TX prepare failure path", " - EDAC/i10nm: Don't fail probing if ADXL is missing", " - watchdog: apple: Add \"apple,t8103-wdt\" compatible", " - tracing: Prevent out-of-bounds read in glob matching", " - NFSv4: include MAY_WRITE in open permission mask for O_TRUNC", " - module: decompress: check return value of module_extend_max_pages()", " - exfat: bound uniname advance in exfat_find_dir_entry()", " - NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()", " - KVM: VMX: Refresh GUEST_PENDING_DBG_EXCEPTIONS.BS on all injected #DBs", " - KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest", " mode", " - udmabuf: fix DMA direction mismatch in release_udmabuf()", " - i2c: core: fix adapter deregistration race", " - i2c: mpc: Fix timeout calculations", " - i2c: stm32f7: truncate clock period instead of rounding it", " - Input: synaptics-rmi4 - unregister function handlers on physical driver", " registration failure", " - Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count", " - Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count", " - Input: elan_i2c - prevent division by zero and arithmetic underflow", " - Input: goodix - clamp the device-reported contact count", " - Input: iforce - bound the device-reported force-feedback effect index", " - Input: mms114 - fix touch indexing for MMS134S and MMS136", " - Input: touchwin - reset the packet index on every complete packet", " - Input: mms114 - reject an oversized device packet size", " - Input: maplemouse - fix NULL pointer dereference in open()", " - Input: mms114 - fix multi-touch slot corruption", " - Input: maple_keyb - set driver data before registering input device", " - Input: maplemouse - set driver data before registering input device", " - Input: maplecontrol - set driver data before registering input device", " - RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", " - fuse: fix device node leak in cuse_process_init_reply()", " - fuse: re-lock request before returning from fuse_ref_folio()", " - smb: client: reject overlapping data areas in SMB2 responses", " - xfs: fail recovery on a committed log item with no regions", " - xfs: resample the data fork mapping after cycling ILOCK", " - smb/server: do not require delete access for non-replacing links", " - sched/fair: Only update stats for allowed CPUs when looking for dst", " group", " - KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU", " - KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove CRYPTO_DEV_SUN4I_SS_PRNG", " - crypto: crypto4xx - Remove ahash-related code", " - bpf: Support for hardening against JIT spraying", " - x86/bugs: Enable IBPB flush on BPF JIT allocation", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix sequence number when no EOF", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - dt-bindings: power: imx93: Add MIPI PHY power domain", " - serial: msm: Disable DMA for kernel console UART", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: Fix further netns teardown to cancel the preallocation charger", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/amdgpu: fix integer overflow in amdgpu_gem_align_pitch()", " - drm/radeon: fix integer overflow in radeon_align_pitch()", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " - libbpf: Report error when a negative kprobe offset is specified", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg", " warning", " - wifi: cfg80211: fix grammar in MLO group key error message", " - arm64: tegra: Fix Tegra234 MGBE PTP clock", " - dt-bindings: pinctrl: nvidia,tegra234: Add missing required block", " - drm/amdkfd: Validate CRIU-restored IDs before idr_alloc", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sama5d4_wdt: Fix WDDIS detection on SAM9X60 and SAMA7G5", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - media: v4l2-common: Add YUV24 format info", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " - dlm: fix add msg handle in send_queue ordered", " - nilfs2: fix backing_dev_info reference leak", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - evm: terminate and bound the evm_xattrs read buffer", " - thermal: hwmon: Fix critical temperature attribute removal", " - clk: scpi: Unregister child clock providers on remove", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - spi: hisi-kunpeng: Use dev_err_probe() for host registration failure", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/srpt: fix integer overflow in immediate data length check", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - driver core: Use mod_delayed_work to prevent lost deferred probe work", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - bus: sunxi-rsb: Always check register address validity", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: seq: midi: Serialize output teardown with event_input", " - pinctrl: cs42l43: Fix polarity on debounce", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " - drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X", " client is registered", " - drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove", " - gpu: host1x: Allow entries in BO caches to be freed", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - gpu: host1x: Fix iommu_map_sgtable() return value check", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Harden parse_vma_segs() path parsing", " - libbpf: Fix UAF in strset__add_str()", " - dax/kmem: account for partial discontiguous resource upon removal", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - rpmsg: use generic driver_override infrastructure", " - md/raid10: reset read_slot when reusing r10bio for discard", " - RDMA/siw: bound Read Response placement to the RREAD length", " - block: skip sync_blockdev() on surprise removal in bdev_mark_dead()", " - crypto: algif_skcipher - force synchronous processing", " - crypto: crypto4xx - Remove insecure and unused rng_alg", " - crypto: hisi-trng - Remove crypto_rng interface", " - bpf: Restrict JIT predictor flush to cBPF", " - bpf: Skip redundant IBPB in pack allocator", " - bpf: Prefer packs that won't trigger an IBPB flush on allocation", " - bpf: Prefer dirty packs for eBPF allocations", " - clk: scmi: Fix clock rate rounding", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - bitops: use common function parameter names", " - media: rockchip: rga: fix too small buffer size", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - scsi: ufs: Fix wrong value printed in unexpected UPIU response case", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " - mm/fake-numa: fix under-allocation detection in uniform split", " - ext2: fix ignored return value of generic_write_sync()", " - sched: restore timer_slack_ns when resetting RT policy on fork", " - lib/test_meminit: use && for bools", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: reject FITRIM ranges shorter than a cluster", " - ocfs2/dlm: require a ref for locking_state debugfs open", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - bpf: Check tail zero of bpf_prog_info", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - wifi: wcn36xx: fix heap overflow from oversized firmware HAL response", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " - wifi: wcn36xx: fix OOB read from short trigger BA firmware response", " - ALSA: seq: Fix partial userptr event expansion", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - scsi: target: Fix hexadecimal CHAP_I handling", " - scsi: target: Remove tcm_loop target reset handling", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " - hwspinlock: qcom: avoid uninitialized struct members", " - sched/fair: Fix cpu_util runnable_avg arithmetic", " - wifi: mt76: fix argument to ieee80211_is_first_frag()", " - wifi: mt76: mt7915: fix potential tx_retries underflow", " - wifi: mt76: mt7921: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - spi: meson-spifc: fix runtime PM leak on remove", " - ASoC: codecs: aw88261: fix incorrect masks for boost regs", " - vduse: hold vduse_lock across IDR lookup in open path", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " - vduse: Requeue failed read to send_list head", " - vhost/net: complete zerocopy ubufs only once", " - tools/virtio: check mmap return value in vringh_test", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - bonding: 3ad: fix mux port state on oper down", " - ext4: fix kernel BUG in ext4_write_inline_data_end", " - selftests/bpf: Fix bpf_iter/task_vma test", " - cxl/test: Fix integer overflow in mock LSA bounds checks", " - cxl/test: Zero out LSA backing memory to avoid leaking to user", " - of: cpu: add check in __of_find_n_match_cpu_property()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " - RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " - ASoC: fsl: fsl_audmix: Validate written enum values", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " - net/sched: cls_flow: Dont expose folded kernel pointers", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " - bridge: cfm: reject invalid CCM interval at configuration time", " - sctp: validate embedded address parameter length", " - net/sched: sch_hfsc: Don't make class passive twice", " - tipc: require net admin for TIPCv2 netlink mutators", " - tipc: prevent snt_unacked underflow on CONN_ACK", " - tipc: reject inverted service ranges from peer bindings", " - cxl/test: Add check after kzalloc() memory in alloc_mock_res()", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " - crypto: rng - Free default RNG on module exit", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - power: supply: core: fix supplied_from allocations", " - handshake: Require admin permission for DONE command", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - net: wwan: t7xx: check skb_clone in control TX", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - netfilter: nf_conncount: callers must hold rcu read lock", " - ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait()", " - cifs: remove all cifs files before kill super", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - tipc: fix UAF in tipc_l2_send_msg()", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - ionic: Fix check in ionic_get_link_ext_stats", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - coresight: cti: Fix DT filter signals silently ignored", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - PCI/ASPM: Don't reconfigure ASPM entering low-power state", " - PCI: Introduce named defines for PCI ROM", " - PCI: Check ROM header and data structure addr before accessing", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - mailbox: mtk-adsp: fix UAF during device teardown", " - staging: most: video: avoid double free on video register failure", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " - iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " - iio: tcs3472: power down chip on probe failure", " - clk: at91: keep securam node alive while mapping it", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - fs/ntfs3: add bounds check to run_get_highest_vcn()", " - fs/ntfs3: fix mount failure on 64K page-size kernels", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - pNFS/filelayout: fix cheking if a layout is striped", " - xprtrdma: Remove temp allocation of rpcrdma_rep objects", " - xprtrdma: Avoid 250 ms delay on backlog wakeup", " - xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot", " - xprtrdma: Post receive buffers after RPC completion", " - xprtrdma: Use sendctx DMA state for Send signaling", " - xprtrdma: Decouple req recycling from RPC completion", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - nfs: keep PG_UPTODATE clear after read errors in page groups", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Fix bcall rep leak and unbounded peek", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - apparmor: fix rawdata_f_data implicit flex array", " - apparmor: fix potential UAF in aa_replace_profiles", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - sparc: led: avoid trimming a newline from empty writes", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - spi: dw: fix wrong BAUDR setting after resume", " - xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO", " path", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " - PCI: iproc: Restore .map_irq() for the platform bus driver", " - spi: rpc-if: Use correct device for hardware reinitialization on resume", " - virtio-net: fix len check in receive_big()", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - flow_dissector: check device type before reading ETH_ADDRS", " - ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: Fix data race between add and dump in all hash types", " - netfilter: ipset: annotate \"pos\" for concurrent readers/writers", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash", " types", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - irqchip/crossbar: Fix parent domain resource leak", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - net: marvell: prestera: initialize err in prestera_port_sfp_bind", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " - net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths", " - octeontx2-af: mcs: Fix unsupported secy stats read", " - octeontx2-pf: Clear stats of all resources when freeing resources", " - octeontx2-pf: mcs: Fix mcs resources free on PF shutdown", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: Fix stack slot index in nospec checks", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()", " - ice: fix AQ error code comparison in ice_set_pauseparam()", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - ipv4: fib: Don't ignore error route in local/main tables.", " - bpf, lsm: Add disabled BPF LSM hook list", " - bpf: Disable xfrm_decode_session hook attachment", " - netfilter: nf_nat: avoid invalid nat_net pointer use on failed", " nf_nat_init()", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - netfilter: nft_compat: ebtables emulation must reject non-bridge targets", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - NTB: epf: Report 0-based doorbell vector via ntb_db_event()", " - NTB: epf: Fix doorbell bitmask and IRQ vector handling", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - net, bpf: check master for NULL in xdp_master_redirect()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - net: mvneta: re-enable percpu interrupt on resume", " - net: sungem: fix probe error cleanup", " - net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - net: enetc: check the number of BDs needed for xdp_frame", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - apparmor: check label build before no_new_privs test", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - net/sched: sch_teql: Introduce slaves_lock to avoid race condition and", " UAF", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - cxgb4: Fix decode strings dump for T6 adapters", " - virtio_net: disable cb when NAPI is busy-polled", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - ksmbd: reject undersized DACLs before parsing ACEs", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - pinctrl: meson: restore non-sleeping GPIO access", " - net/sched: hhf: clear heavy-hitter state on reset", " - fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid", " - afs: Fix error code in afs_extract_vl_addrs()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix vllist leak", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " - afs: Fix unchecked-length string display in debug statement", " - minix: avoid overflow in bitmap block count calculation", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: convert READ_ONCE(*ptep) to ptep_get(ptep)", " - arm64/mm: convert set_pte_at() to set_ptes(..., 1)", " - arm64/mm: convert ptep_clear() to ptep_get_and_clear()", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - selftests/hid: convert the hid_bpf selftests with struct_ops", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - gue: validate REMCSUM private option length", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " - amt: fix size calculation in amt_get_size()", " - Bluetooth: 6lowpan: hold L2CAP conn across debugfs control", " - Bluetooth: MGMT: Fix adv monitor add failure cleanup", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - ring-buffer: Fix event length with forced 8-byte alignment", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: move functions to avoid forward definitions", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " - ipv6: mcast: Replace locking comments with lockdep annotations.", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " - s390/zcrypt: Remove the empty file", " - cifs: validate DFS referral string offsets", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " - dm era: fix NULL pointer dereference in metadata_open()", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " - selftests/net: fix EVP_MD_CTX leak in tcp_mmap", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - octeontx2-af: fix VF bringup affecting PF promiscuous state", " - smb: client: fix overflow in passthrough ioctl bounds check", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " - ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put", " - ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc", " - ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get", " - ASoC: SOF: topology: validate vendor array size before parsing", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " - net: atm: reject out-of-range traffic classes in QoS validation", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " - fbdev: vesafb: fix memory leak in vesafb_probe()", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " - ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get", " - ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Release reserved memory on cleanup", " - ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_cluster: reject template conntracks in hash match", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - netfilter: nf_nat_sip: reload possible stale data pointer", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " - netfilter: ecache: fix inverted time_after() check", " - netfilter: xt_nat: reject unsupported target families", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - selinux: check connect-related permissions on TCP Fast Open", " - leds: uleds: Fix potential buffer overread", " - mfd: sm501: Fix reference leak on failed device registration", " - tools/power/x86/intel-speed-select: Harden daemon pidfile open", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " - x86/boot: Reject too long acpi_rsdp= values", " - perf/x86/amd/lbr: Fix kernel address leakage", " - s390/perf_cpum_cf: Add missing array_index_nospec() to", " __hw_perf_event_init()", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: bla: reacquire gw address after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: tt: avoid request storms during pending request", " - batman-adv: fix VLAN priority offset", " - batman-adv: frag: free unfragmentable packet", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: tt: prevent TVLV OOB check overflow", " - cifs: invalidate cfid on unlink/rename/rmdir", " - mfd: tps6586x: Fix OF node refcount", " - HID: playstation: validate num_touch_reports in DualShock 4 reports", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " - nvdimm/btt: Free arenas on btt_init() error paths", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - mm/damon/core: make charge_addr_from aware of end-address exclusivity", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " - fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " - riscv: cacheinfo: Fix node reference leak in populate_cache_leaves", " - mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs()", " - mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error", " - proc: only bump parent nlink when registering directories", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - mtd: rawnand: pl353: fix probe resource allocation", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " - mtd: rawnand: fix condition in 'nand_select_target()'", " - ocfs2: avoid moving extents to occupied clusters", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " - ocfs2: add journal NULL check in ocfs2_checkpoint_inode()", " - ocfs2: reject dinodes with non-canonical i_mode type", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " - fpga: dfl: add bounds check in dfh_get_param_size()", " - bus: mhi: ep: Protect mhi_ep_handle_syserr() in the error path", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - fpga: microchip-spi: fix zero header_size OOB read in", " mpf_ops_parse_header()", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86/amd/pmc: Check for intermediate wakeup in function", " - platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops", " - platform/x86/amd/pmc: Add delay_suspend module parameter", " - smb: client: use kvzalloc() for megabyte buffer in simple fallocate", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - ice: fix ice_init_link() error return preventing probe", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - tpm: Make the TPM character devices non-seekable", " - time: Fix off-by-one in compat settimeofday() usec validation", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " - sctp: validate STALE_COOKIE cause length before reading staleness", " - nvmet-rdma: handle inline data with a nonzero offset", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " - can: bcm: add missing rcu list annotations and operations", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - net: sparx5: unregister blocking notifier on init failure", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " - dm era: fix out-of-bounds memory access for non-zero start sector", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-ioctl: fix a possible overflow in list_version_get_info", " - dm-log: fix a bitset_size overflow on 32bit machines", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm_early_create: fix freeing used table on dm_resume failure", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - scsi: sg: Report request-table problems when any status is set", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - validate control endpoint type", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - Input: ims-pcu - fix race condition in reset_device sysfs callback", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " - net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio-f7188x: Add support for NCT6126D version B", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: wwan: t7xx: destroy DMA pool on CLDMA late init failure", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - net: ena: clean up XDP TX queues when regular TX setup fails", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " - ieee802154: admin-gate legacy LLSEC dump operations", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " - batman-adv: ensure minimal ethernet header on TX", " - batman-adv: clean untagged VLAN on netdev registration failure", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - espintcp: use sk_msg_free_partial to fix partial send", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: mpfs: fix counter upload completion condition", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - net: liquidio: fix BAR resource leak on PF number failure", " - hwmon: (occ) unregister sysfs devices outside occ lock", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - net: lan743x: Initialize eth_syslock spinlock before use", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - net: wwan: iosm: bound device offsets in the MUX downlink decoder", " - hwmon: (asus_atk0110) Check package count before accessing element", " - riscv: probes: save original sp in rethook trampoline", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - drbd: reject data replies with an out-of-range payload size", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " - pmdomain: imx: Fix i.MX8MP power notifier", " - pmdomain: imx: Fix i.MX8MP VC8000E power up sequence", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - Bluetooth: btrtl: validate firmware patch bounds", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - memstick: ms_block: reject a card that reports too many blocks", " - ipvs: fix more places with wrong ipv6 transport offsets", " - ipvs: reload ip header after head reallocation", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: mac80211: free ack status frame on TX header build failure", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " - mtd: onenand: samsung: report DMA completion timeouts", " - mtd: mchp23k256: use SPI match data for chip caps", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " - perf/x86/amd/brs: Fix kernel address leakage", " - ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup", " - ACPI: bus: Introduce devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Use devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Fix possible deadlock and missing notifications", " - iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - iio: invensense: remove redundant initialization of variable period", " - iio: invensense: fix timestamp glitches when switching frequency", " - iio: imu: inv_icm42600: stabilized timestamp in interrupt", " - iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading", " - iio: pressure: mpl115: fix runtime PM leak on read error", " - bitops: make BYTES_TO_BITS() treewide-available", " - iio: common: st_sensors: honour channel endianness in read_axis_data", " - ALSA: aoa: check snd_ctl_new1() return value", " - PCI: altera: Fix resource leaks on probe failure", " - vfio/mlx5: Fix racy bitfields and tighten struct layout", " - PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling", " - PCI: controller: Use dev_fwnode() instead of of_fwnode_handle()", " - PCI: mediatek: Convert bool to single quirks entry and bitmap", " - PCI: mediatek: Use generic MACRO for TPVPERL delay", " - PCI: mediatek: Fix IRQ domain leak when port fails to enable", " - PCI: Prevent resource tree corruption when BAR resize fails", " - PCI: Free saved list without holding pci_bus_sem", " - PCI: Fix restoring BARs on BAR resize rollback path", " - PCI: Add kerneldoc for pci_resize_resource()", " - PCI: Move Resizable BAR code to rebar.c", " - PCI: Skip Resizable BAR restore on read error", " - staging: rtl8723bs: core: move constants to right side in comparison", " - staging: rtl8723bs: fix spaces around binary operators", " - staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),", " rtw_get_wapi_ie(), and rtw_get_wps_attr()", " - crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()", " - Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref", " - mm/shrinker: do not hold RCU lock in shrinker_debugfs_count_show()", " - coresight: etb10: restore atomic_t for shared reading state", " - gpio: sch: use raw_spinlock_t in the irq startup path", " - media: nxp: imx8-isi: Convert to platform remove callback returning void", " - media: nxp: imx8-isi: use devm_pm_runtime_enable() to simplify code", " - media: nxp: imx8-isi: Fix use-after-free on remove", " - netfilter: ebtables: Use vmalloc_array() to improve code", " - netfilter: ebtables: zero chainstack array", " - Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - smb: client: Improve unlocking of a mutex in cifs_get_swn_reg()", " - smb: client: resolve SWN tcon from live registrations", " - ksmbd: use opener credentials for FSCTL mutations", " - ksmbd: centralize ksmbd_conn final release to plug transport leak", " - ksmbd: track the connection owning a byte-range lock", " - proc: rename proc_setattr to proc_nochmod_setattr", " - proc: protect ptrace_may_access() with exec_update_lock (FD links)", " - writeback: fix race between cgroup_writeback_umount() and", " inode_switch_wbs()", " - perf/x86/intel/uncore: Defer ADL global PMON enable to enable_box()", " - HID: add haptics page defines", " - HID: multitouch: fix out-of-bounds bit access on mt_io_flags", " - mm/slab: do not limit zeroing to orig_size when only red zoning is", " enabled", " - seqlock: Introduce scoped_seqlock_read()", " - seqlock: Change do_task_stat() to use scoped_seqlock_read()", " - proc: protect ptrace_may_access() with exec_update_lock (part 1)", " - treewide: Switch/rename to timer_delete[_sync]()", " - HID: appleir: fix UAF on pending key_up_timer in remove()", " - serial: 8250_mid: Disable DMA for selected platforms", " - hfs/hfsplus: prevent getting negative values of offset/length", " - hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length", " - bpf: Consistently use bpf_rcu_lock_held() everywhere", " - bpf: Allow LPM map access from sleepable BPF programs", " - usb: iowarrior: remove inherent race with minor number", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - usb: typec: tcpm: Fix VDM type for Enter Mode commands", " - crypto: atmel - Drop explicit initialization of struct", " i2c_device_id::driver_data to 0", " - crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A", " - usb: gadget: f_fs: initialize reset_work at allocation time", " - nvmet: return DHCHAP status codes from nvmet_setup_auth()", " - nvmet-auth: validate reply message payload bounds against transfer", " length", " - usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile", " - btrfs: check and set EXTENT_DELALLOC_NEW before clearing EXTENT_DELALLOC", " - crypto: qat - fix restarting state leak on allocation failure", " - audit: add audit_log_nf_skb helper function", " - audit: fix potential integer overflow in audit_log_n_hex()", " - regulator: scmi: Simplify with scoped for each OF child loop", " - regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()", " - mm: do file ownership checks with the proper mount idmap", " - exfat: move free cluster out of exfat_init_ext_entry()", " - exfat: remove unnecessary read entry in __exfat_rename()", " - exfat: rename argument name for exfat_move_file and exfat_rename_file", " - exfat: add exfat_get_dentry_set_by_ei() helper", " - exfat: move exfat_chain_set() out of __exfat_resolve_path()", " - exfat: preserve benign secondary entries during rename and move", " - btrfs: fix false IO failure after falling back to buffered write", " - btrfs: fix incorrect buffered IO fallback for append direct writes", " - Bluetooth: hci_core: Enable buffer flow control for SCO/eSCO", " - Bluetooth: separate CIS_LINK and BIS_LINK link types", " - Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - seqlock: fix scoped_seqlock_read kernel-doc", " - Bluetooth: hci_core: Remove check of BDADDR_ANY in", " hci_conn_hash_lookup_big_state", " - Bluetooth: hci_sync: Fix attempting to send HCI_Disconnect to BIS handle", " - Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote", " netdev", " - selftests/hid: ensure CKI can compile our new tests on old kernels", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error harder", " - Bluetooth: btmtk: remove #ifdef around declarations", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - jiffies: Define secs_to_jiffies()", " - jiffies: Cast to unsigned long in secs_to_jiffies() conversion", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - tools/testing: add linux/args.h header and fix radix, VMA tests", " - selftests/bpf: Add simple strscpy() implementation", " - bcachefs: avoid truncating fiemap extent length", " - gpio: rockchip: change the GPIO version judgment logic", " - gpio: rockchip: teardown bugs and resource leaks", " - gpio: rockchip: fix generic IRQ chip leak on remove", " - NFSv4/flexfiles: Remove cred local variable dependency", " - iio: resolver: ad2s1210: notify trigger and clear state on fault read", " error", " - iio: temperature: Build mlx90635 with CONFIG_MLX90635", " - vfio: Remove device debugfs before releasing devres", " - PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000", " series", " - netpoll: fix a use-after-free on shutdown path", " - mm: shrinker: fix shrinker_info teardown race with expansion", " - NFSv4/flexfiles: Add data structure support for striped layouts", " - mm/khugepaged: write all dirty file folios when collapsing", " - platform/x86: intel-hid: Protect ACPI notify handler against recursion", " - Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled", " - Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()", " - fs/ntfs3: rename ni_readpage_cmpr into ni_read_folio_cmpr", " - ksmbd: use __GFP_RETRY_MAYFAIL", " - ksmbd: use opener credentials for ADS I/O", " - cpufreq: Make cpufreq_driver->exit() return void", " - cpufreq: qcom-cpufreq-hw: Fix possible double free", " - nvme: target: rdma: fix ndev refcount leak on queue connect", " - nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page", " - crypto: qat - keep VFs enabled during reset", " - crypto: qat - notify fatal error before AER reset preparation", " - crypto: qat - protect service table iterations with service_lock", " - selftests/mm: pagemap_ioctl: use the correct page size for", " transact_test()", " - iommufd: Set upper bounds on cache invalidation entry_num and entry_len", " - iommu/amd: Don't split flush for amd_iommu_domain_flush_all()", " - dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning", " - i2c: core: fix adapter probe deferral loop", " - xfs: fix null pointer dereference in tracepoint", " - xfs: don't wrap around quota ids in dqiterate", " - xfs: clamp timestamp nanoseconds correctly", " - xfs: don't zap bmbt forks if they are MAXLEVELS tall", " - iommu/vt-d: Clear Present bit before tearing down context entry", " - iommu: Pass old domain to set_dev_pasid op", " - iommu/vt-d: Cleanup intel_context_flush_present()", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " - vsock/virtio: bind uarg before filling zerocopy skb", " - iommu/amd: Use maximum Event log buffer size when SNP is enabled on", " Family 0x19", " - iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family", " 0x19", " - net: dropreason: Gather SOCKET_ drop reasons.", " - af_unix: Set drop reason in unix_release_sock().", " - af_unix: Set drop reason in manage_oob().", " - af_unix: Set drop reason in unix_stream_read_skb().", " - af_unix/scm: fix whitespace errors", " - af_unix: Don't hold unix_state_lock() in __unix_dgram_recvmsg().", " - af_unix: Don't check SOCK_DEAD in unix_stream_read_skb().", " - af_unix: Don't use skb_recv_datagram() in unix_stream_read_skb().", " - af_unix: Drop all SCM attributes for SOCKMAP.", " - time/jiffies: Change register_refined_jiffies() to void __init", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - media: uvcvideo: Do not add clock samples with small sof delta", " - serial: max310x: replace bare use of 'unsigned' with 'unsigned int'", " (checkpatch)", " - serial: max310x: implement gpio_chip::get_direction()", " - drm/gpuvm: Do not prepare NULL objects", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - soc: xilinx: Shutdown and free rx mailbox channel", " - crypto: qat - fix heartbeat error injection", " - memory: tegra: Wire up system sleep PM ops", " - drm/gpuvm: take refcount on DRM device", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - RDMA/hns: Initialize seqfile before creating file", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - RDMA/hns: Fix log flood after cmd_mbox failure", " - net: introduce page_frag_cache_drain()", " - nvmet-tcp: fix page fragment cache leak in error path", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - driver core: Use system_percpu_wq instead of system_wq", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - x86/cpu/amd: Provide a separate accessor for Node ID", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - netfilter: nfnetlink_cthelper: use {READ,WRITE}_ONCE for accessing", " helper flags", " - netfilter: synproxy: drop packets if timestamp adjustment fails", " - netfilter: synproxy: adjust duplicate timestamp options", " - netfilter: synproxy: fix unaligned memory access in timestamp adjustment", " - RDMA/siw: Fix endpoint/socket association handling", " - riscv: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - virtio_console: read size from config space during device init", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - net: dsa: qca8k: fix led devicename when using external mdio bus", " - ALSA: seq: Drop superfluous filter argument of get_event_dest_client()", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - dpll: add reference-sync netlink attribute", " - dpll: move xa_erase() call in to match dpll_pin_alloc() error path order", " - dpll: add reference sync get/set", " - dpll: Allow associating dpll pin with a firmware node", " - dpll: Add notifier chain for dpll events", " - dpll: Support dynamic pin index allocation", " - dpll: Enhance and consolidate reference counting logic", " - dpll: fix stale iteration in dpll_pin_on_pin_unregister()", " - dpll: send delete notification before unregister in on-pin rollback", " - dpll: emit per-dpll delete notifications in dpll_pin_on_pin_unregister()", " - dpll: guard sync-pair removal on full pin unregister", " - dpll: balance create/delete notifications in __dpll_pin_(un)register", " - landlock: Fix unmarked concurrent access to socket family", " - selftests/bpf: Fix typo in verify_umulti_link_info", " - udf: fix nls leak on udf_fill_super() failure", " - mfd: rsmu: Fix page register setup", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: split ep_insert() into alloc + register stages", " - eventpoll: extract ep_deliver_event() from ep_send_events()", " - eventpoll: wrap EP_UNACTIVE_PTR in typed sentinel helpers", " - eventpoll: rename epi->next and txlist for clarity", " - eventpoll: Fix epoll_wait() report false negative", " - gpiolib: acpi: Only trigger ActiveBoth interrupts on boot", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - PCI: meson: Add missing remove callback", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - workqueue: Add new WQ_PERCPU flag", " - i3c: master: add WQ_PERCPU to alloc_workqueue users", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - xfrm: Fix xfrm state cache insertion race", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - netfilter: ipset: make sure gc is properly stopped", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: hugetlb_reparenting_test: do not unmount", " - selftests/mm: save and restore nr_hugepages value", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - ipv6: annotate data-races around cnf.forwarding", " - ipv6/addrconf: annotate data-races around devconf fields (II)", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_info", " - ice: dpll: fix memory leak in ice_dpll_init_info error paths", " - net: bnxt: use ethtool string helpers", " - eth: bnxt: gather and report HW-GRO stats", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - ipv6: Add __in6_dev_get_rtnl_net().", " - octeontx2-af: Validate NIX maximum LFs correctly", " - udp_tunnel: remove rtnl_lock dependency", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - net: hisilicon: hns3: use ethtool string helpers", " - net: hns3: use string choices helper", " - net: hns3: use hns3_get_ae_dev() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: use hns3_get_ops() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: clear hns alarm: comparison of integer expressions of", " different signedness", " - net: hns3: unify copper port ksettings configuration path", " - net: hns3: refactor MAC autoneg and speed configuration", " - net: hns3: fix permanent link down deadlock after reset", " - net: hns3: differentiate autoneg default values between copper and fiber", " - rtnetlink: Add per-netns RTNL.", " - [Config] Set CONFIG_DEBUG_NET_SMALL_RTNL=n", " - rtnetlink: Add assertion helpers for per-netns RTNL.", " - rtnetlink: Define rtnl_net_trylock().", " - ipv6: Convert net.ipv6.conf.${DEV}.XXX sysctl to per-netns RTNL.", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Make /afs/. as well as /afs/ mountpoints", " - afs: Add rootcell checks", " - afs: Make /afs/@cell and /afs/.@cell symlinks", " - afs: Fix afs_atcell_get_link() to handle RCU pathwalk", " - afs: Remove the \"autocell\" mount option", " - afs: Change dynroot to create contents on demand", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - ovl: fix comment about locking order", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - afs: Convert comma to semicolon", " - afs: Fix double netfs initialisation in afs_root_iget()", " - drm/xe: Add warn when level can not be zero.", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - HID: bpf: Fix hid_bpf_get_data() range check", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - genirq/generic_chip: Introduce irq_domain_{alloc,remove}_generic_chips()", " - gpio: mvebu: free generic chips on unbind", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " - drm/xe: remove duplicate include", " - LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()", " - LoongArch: KVM: Check the return values for put_user()", " - LoongArch: KVM: Fix FPU register width with user access API", " - LoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr()", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - fbdev: efifb: fix memory leak in efifb_probe()", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - batman-adv: mcast: avoid OOB read of num_dests header", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()", " - fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry()", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - taskstats: retain dead thread stats in TGID queries", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - NFS: Charge unstable writes by request size, not folio size", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: make error counter atomic", " - accel/ivpu: Reject firmware log with size smaller than header", " - firmware_loader: introduce __free() cleanup hanler", " - Input: ims-pcu - fix firmware leak in async update", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - gpio: tegra: do not call pinctrl for GPIO direction", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - s390: Revert support for DCACHE_WORD_ACCESS", " - [Config] Set CONFIG_DCACHE_WORD_ACCESS=- for s390x", " - selftests: net: make busywait timeout clock portable", " - ata: libata: Use QUIRK instead of HORKAGE", " - ata: libata-core: Skip HPA resize for locked drives", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - ALSA: hda/cs35l41: Fix firmware load work teardown", " - io_uring/rw: ensure reissue path is correctly handled for IOPOLL", " - io_uring/rw: preserve partial result for iopoll", " - Bluetooth: L2CAP: Fix not tracking outstanding TX ident", " - mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless", " host", " - ksmbd_vfs_rename(): vfs_path_parent_lookup() accepts ERR_PTR() as name", " - vfs: make LAST_XXX private to fs/namei.c", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " - HID: pidff: Fix missing blank lines after declarations", " - HID: pidff: Add missing spaces", " - HID: pidff: Rework pidff_upload_effect", " - HID: pidff: Use correct effect type in effect update", " - bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()", " - USB: iowarrior: fix use-after-free on disconnect race", " - crypto: atmel-sha204a - fail on hwrng registration error in probe path", " - btrfs: concentrate the error handling of submit_one_sector()", " - btrfs: remove folio parameter from ordered io related functions", " - btrfs: remove the COW fixup mechanism", " - slab: Introduce kmalloc_obj() and family", " - slab: Introduce kmalloc_flex() and family", " - add default_gfp() helper macro and use it in the new *alloc_obj()", " helpers", " - default_gfp(): avoid using the \"newfangled\" __VA_OPT__ trick", " - slab: recognize @GFP parameter as optional in kernel-doc", " - fscrypt: Fix key setup in edge case with multiple data unit sizes", " - fscrypt: Replace mk_users keyring with simple list", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is", " uninitialized", " - rtnetlink: Make per-netns RTNL dereference helpers to macro.", " - afs: Fix afs_atcell_get_link() to check if ws_cell is unset first", " - afs: Fix afs_dynroot_readdir() to not use the RCU read lock", " - udp_tunnel: fix deadlock in udp_tunnel_nic_set_port_priv()", " - i40e: drop udp_tunnel_get_rx_info() call from i40e_open()", " - ice: drop udp_tunnel_get_rx_info() call from ndo_open()", " - Bluetooth: L2CAP: Fix regressions caused by reusing ident", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " - perf: Reject exited events as group leaders", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - proc: Fix broken error paths for namespace links", " - Upstream stable to v6.6.145, v6.12.96, v6.12.97", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2026-53365", " - vsock/virtio: fix zerocopy completion for multi-skb sends", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two", " - x86/mm: Fix check/use ordering in switch_mm_irqs_off()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192)", " - debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING", " - debugobjects: Use LD_WAIT_CONFIG instead of LD_WAIT_SLEEP", " - debugobjects: Dont call fill_pool() in early boot hardirq context", " - ARM: group is_permission_fault() with is_translation_fault()", " - ARM: allow __do_kernel_fault() to report execution of memory faults", " - ARM: fix branch predictor hardening", " - RDMA/bnxt_re: zero shared page before exposing to userspace", " - selftests/bpf: Add test to ensure kprobe_multi is not sleepable", " - bpf: Remove mark_precise_scalar_ids()", " - selftests/bpf: Tests for per-insn sync_linked_regs() precision tracking", " - selftests/bpf: Update comments find_equal_scalars->sync_linked_regs", " - hv: utils: handle and propagate errors in kvp_register", " - Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs", " - phonet: Pass ifindex to fill_addr().", " - phonet: Pass net and ifindex to phonet_address_notify().", " - scripts/sorttable: Remove unused macro defines", " - scripts/sorttable: Remove unused write functions", " - scripts/sorttable: Remove unneeded Elf_Rel", " - scripts/sorttable: Have the ORC code use the _r() functions to read", " - scripts/sorttable: Make compare_extable() into two functions", " - scripts/sorttable: Convert Elf_Ehdr to union", " - scripts/sorttable: Replace Elf_Shdr Macro with a union", " - scripts/sorttable: Convert Elf_Sym MACRO over to a union", " - scripts/sorttable: Add helper functions for Elf_Ehdr", " - scripts/sorttable: Add helper functions for Elf_Shdr", " - scripts/sorttable: Add helper functions for Elf_Sym", " - scripts/sorttable: Use uint64_t for mcount sorting", " - scripts/sorttable: Move code from sorttable.h into sorttable.c", " - scripts/sorttable: Get start/stop_mcount_loc from ELF file directly", " - scripts/sorttable: Use a structure of function pointers for elf helpers", " - arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64", " - [Config] Set configs to sort mcount_loc at boot for arm64", " - scripts/sorttable: Have mcount rela sort use direct values", " - scripts/sorttable: Always use an array for the mcount_loc sorting", " - scripts/sorttable: Zero out weak functions in mcount_loc table", " - ftrace: Update the mcount_loc check of skipped entries", " - ftrace: Have ftrace pages output reflect freed pages", " - ftrace: Do not over-allocate ftrace memory", " - ftrace: Test mcount_loc addr before calling ftrace_call_addr()", " - ftrace: Check against is_kernel_text() instead of kaslr_offset()", " - scripts/sorttable: Use normal sort if theres no relocs in the mcount", " section", " - scripts/sorttable: Allow matches to functions before function entry", " - scripts/sorttable: Fix endianness handling in build-time mcount sort", " - file: add fput() cleanup helper", " - eventpoll: use hlist_is_singular_node() in __ep_remove()", " - Revert \"ptp: add testptp mask test\"", " - Bluetooth: btmtk: validate WMT event SKB length before struct access", " - Bluetooth: btmtk: accept too short WMT FUNC_CTRL events", " - batman-adv: tp_meter: keep unacked list in ascending ordered", " - batman-adv: tp_meter: initialize dup_acks explicitly", " - batman-adv: tp_meter: initialize dec_cwnd explicitly", " - batman-adv: tp_meter: avoid window underflow", " - batman-adv: tp_meter: fix fast recovery precondition", " - batman-adv: tp_meter: handle seqno wrap-around for fast recovery", " detection", " - batman-adv: tp_meter: add only finished tp_vars to lists", " - batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE", " - batman-adv: prevent ELP transmission interval underflow", " - batman-adv: tp_meter: initialize last_recv_time during init", " - batman-adv: ensure bcast is writable before modifying TTL", " - batman-adv: fix (m|b)cast csum after decrementing TTL", " - batman-adv: frag: ensure fragment is writable before modifying TTL", " - batman-adv: frag: avoid underflow of TTL", " - batman-adv: tp_meter: annotate last_recv_time access with", " READ/WRITE_ONCE", " - batman-adv: tp_meter: prevent parallel modifications of last_recv", " - batman-adv: tp_meter: handle overlapping packets", " - batman-adv: tt: don't merge change entries with different VIDs", " - batman-adv: tt: track roam count per VID", " - batman-adv: dat: prevent false sharing between VLANs", " - batman-adv: tvlv: enforce 2-byte alignment", " - batman-adv: tvlv: avoid race of cifsnotfound handler state", " - inet: add indirect call wrapper for getfrag() calls", " - err.h: use __always_inline on all error pointer helpers", " - wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S", " - wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor", " - wifi: rtw88: increase TX report timeout to fix race condition", " - wifi: iwlwifi: mvm: fix race condition in PTP removal", " - f2fs: fix to round down start offset of fallocate for pin file", " - f2fs: keep atomic write retry from zeroing original data", " - MIPS: DEC: Prevent initial console buffer from landing in XKPHYS", " - fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode", " - nfsd: check get_user() return when reading princhashlen", " - NFS: Prevent resource leak in nfs_alloc_server()", " - serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero", " - wifi: mt76: mt7921: avoid undesired changes of the preset regulatory", " domain", " - ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()", " - xfs: fix error returns in CoW fork repair", " - locking/mutex: Remove wakeups from under mutex::wait_lock", " - net: ipv6: Make udp_tunnel6_xmit_skb() void", " - Revert \"PCI: qcom: Advertise Hotplug Slot Capability with no Command", " Completion support\"", " - KVM: SEV: Ignore MMIO requests of length '0'", " - mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program", " - mtd: spi-nor: macronix: add support for mx66{l2, u1}g45g", " - LoongArch: Report dying CPU to RCU in stop_this_cpu()", " - MIPS: smp: report dying CPU to RCU in stop_this_cpu()", " - locking: rtmutex: Fix wake_q logic in task_blocks_on_rt_mutex", " - bonding: annotate data-races arcound churn variables", " - Upstream stable to v6.6.144, v6.12.95", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53389", " - net/tcp-ao: fix use-after-free of key in del_async path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53393", " - nfsd: reset write verifier on deferred writeback errors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53400", " - i2c: core: fix adapter registration race", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63806", " - KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with", " get_unaligned()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63940", " - KVM: SEV: Ignore Port I/O requests of length '0'", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53387", " - iio: light: veml6075: add bounds check to veml6075_it_ms index", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53070", " - sctp: disable BH before calling udp_tunnel_xmit_skb()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43216", " - net: Drop the lock in skb_may_tx_timestamp()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64244", " - drivers/base/memory: set mem->altmap after successful device", " registration", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53384", " - serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53390", " - ksmbd: fix out-of-bounds read in smb_check_perm_dacl()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53391", " - NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53397", " - nfsd: fix posix_acl leak on SETACL decode failure", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64245", " - fbdev: modedb: fix a possible UAF in fb_find_mode()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53403", " - fbdev: Fix fb_new_modelist to prevent null-ptr-deref in", " fb_videomode_to_var", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64246", " - power: reset: linkstation-poweroff: fix use-after-free in the", " linkstation_poweroff_init()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63794", " - KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64247", " - KVM: x86: hyper-v: Bound the bank index when querying sparse banks", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63795", " - 9p: avoid putting oldfid in p9_client_walk() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63796", " - ocfs2: reject oversized group bitmap descriptors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63797", " - rpmsg: char: Fix use-after-free on probe error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64249", " - fpga: region: fix use-after-free in child_regions_with_firmware()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63798", " - irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup", " on remove", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63801", " - tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63802", " - blk-cgroup: fix UAF in __blkcg_rstat_flush()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63803", " - hdlc_ppp: sync per-proto timers before freeing hdlc state", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63804", " - gfs2: fix use-after-free in gfs2_qd_dealloc", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63809", " - bpf: use kvfree() for replaced sysctl write buffer", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63812", " - f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63814", " - f2fs: validate ACL entry sizes in f2fs_acl_from_disk()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63817", " - f2fs: validate compress cache inode only when enabled", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63821", " - wifi: rtw88: usb: fix memory leaks on USB write failures", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63822", " - wifi: ath11k: fix warning when unbinding", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63823", " - keys: Pin request_key_auth payload in instantiate paths", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63824", " - KEYS: fix overflow in keyctl_pkey_params_get_2()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63826", " - fbdev: fix use-after-free in store_modes()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64254", " - NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG", " share BAR", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63827", " - apparmor: fix use-after-free in rawdata dedup loop", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63828", " - apparmor: mediate the implicit connect of TCP fast open sendmsg", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63830", " - net: skmsg: preserve sg.copy across SG transforms", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63831", " - mac802154: llsec: add skb_cow_data() before in-place crypto", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53361", " - af_unix: Set gc_in_progress to true in unix_gc().", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63833", " - ntfs3: reject direct userspace writes to reserved $LX* xattrs", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53366", " - ipv4: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53362", " - ipv6: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63834", " - batman-adv: tp_meter: restrict number of unacked list entries", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63835", " - batman-adv: v: prevent OGM aggregation on disabled hardif", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63836", " - batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63807", " - KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping", " level", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53381", " - virtiofs: fix UAF on submount umount", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53382", " - media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53383", " - ksmbd: reject non-VALID session in compound request branch", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53385", " - vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent", " vcs_write", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53388", " - fuse: re-lock request before replacing page cache folio", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53157", " - net: phonet: free phonet_device after RCU grace period", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53163", " - locking/rtmutex: Skip remove_waiter() when waiter is not enqueued", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2025-23131", " - dlm: prevent NPD when writing a positive value to event_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-46252", " - regulator: core: fix locking in regulator_resolve_supply() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52928", " - af_unix: Reject SIOCATMARK on non-stream sockets", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43010", " - bpf: Reject sleepable kprobe_multi programs at attach time", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53325", " - agp/amd64: Fix broken error propagation in agp_amd64_probe()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64188", " - net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64191", " - i2c: stub: Reject I2C block transfers with invalid length", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53327", " - debugobjects: Do not fill_pool() if pi_blocked_on", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52909", " - ip6_vti: set netns_immutable on the fallback device.", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53167", " - fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios", "" ], "package": "linux", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 11:03:24 +0200" }, { "cves": [ { "cve": "CVE-2026-53132", "url": "https://ubuntu.com/security/CVE-2026-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: \t(Number of skbs in the queue) * SKB_TRUESIZE(0)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53140", "url": "https://ubuntu.com/security/CVE-2026-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53156", "url": "https://ubuntu.com/security/CVE-2026-53156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53202", "url": "https://ubuntu.com/security/CVE-2026-53202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53205", "url": "https://ubuntu.com/security/CVE-2026-53205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53210", "url": "https://ubuntu.com/security/CVE-2026-53210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-31663", "url": "https://ubuntu.com/security/CVE-2026-31663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-53220", "url": "https://ubuntu.com/security/CVE-2026-53220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53229", "url": "https://ubuntu.com/security/CVE-2026-53229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46203", "url": "https://ubuntu.com/security/CVE-2026-46203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: fix unclocked access on unbind Make sure that the controller is runtime resumed before disabling it during driver unbind to avoid an unclocked register access. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-63871", "url": "https://ubuntu.com/security/CVE-2026-63871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock(). These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN. Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route(). BUG: KCSAN: data-race in memcmp+0x45/0xb0 race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1: memcmp+0x45/0xb0 hci_get_route+0x27e/0x490 iso_connect_cis+0x4c/0xa10 iso_sock_connect+0x60e/0xb30 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53251", "url": "https://ubuntu.com/security/CVE-2026-53251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63869", "url": "https://ubuntu.com/security/CVE-2026-63869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap When parsing the radiotap header of an injected frame, ieee80211_parse_tx_radiotap() uses the IEEE80211_RADIOTAP_ANTENNA value directly as a shift count: \tinfo->control.antennas |= BIT(*iterator.this_arg); *iterator.this_arg is an 8-bit value taken straight from the frame supplied by userspace, so BIT() can be asked to shift by up to 255. That is undefined behaviour on the unsigned long and is reported by UBSAN: UBSAN: shift-out-of-bounds in net/mac80211/tx.c:2174:30 shift exponent 235 is too large for 64-bit type 'unsigned long' Call Trace: ieee80211_parse_tx_radiotap+0xadb/0x1950 net/mac80211/tx.c:2174 ieee80211_monitor_start_xmit+0xb1f/0x1250 net/mac80211/tx.c:2451 ... packet_sendmsg+0x3eb6/0x50f0 net/packet/af_packet.c:3109 info->control.antennas is a 2-bit bitmap (u8 antennas:2), so only antenna indices 0 and 1 can ever be represented. Ignore any larger value instead of shifting out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53261", "url": "https://ubuntu.com/security/CVE-2026-53261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53262", "url": "https://ubuntu.com/security/CVE-2026-53262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52908", "url": "https://ubuntu.com/security/CVE-2026-52908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63883", "url": "https://ubuntu.com/security/CVE-2026-63883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64528", "url": "https://ubuntu.com/security/CVE-2026-64528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53329", "url": "https://ubuntu.com/security/CVE-2026-53329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Use krealloc_array() in dal_vector_reserve() [Why & How] dal_vector_reserve() computes the allocation size as \"capacity * vector->struct_size\" using uint32_t arithmetic, which can silently wrap to a small value on overflow. This would cause krealloc to return a smaller buffer than expected, leading to heap overflows on subsequent vector appends. Replace krealloc() with krealloc_array() which performs an internal overflow check and returns NULL on wrap, preventing the issue. (cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707)", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53143", "url": "https://ubuntu.com/security/CVE-2026-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53144", "url": "https://ubuntu.com/security/CVE-2026-53144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53331", "url": "https://ubuntu.com/security/CVE-2026-53331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53147", "url": "https://ubuntu.com/security/CVE-2026-53147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53154", "url": "https://ubuntu.com/security/CVE-2026-53154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c (\"mm: hwpoison: support recovery from HugePage copy-on-write faults\") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53336", "url": "https://ubuntu.com/security/CVE-2026-53336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53337", "url": "https://ubuntu.com/security/CVE-2026-53337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, \"slave_dev=%p:\\n\", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, \"(slave %s): \" fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53160", "url": "https://ubuntu.com/security/CVE-2026-53160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53339", "url": "https://ubuntu.com/security/CVE-2026-53339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53182", "url": "https://ubuntu.com/security/CVE-2026-53182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53183", "url": "https://ubuntu.com/security/CVE-2026-53183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63867", "url": "https://ubuntu.com/security/CVE-2026-63867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close TOCTOU race while computing rcv_wnd The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53343", "url": "https://ubuntu.com/security/CVE-2026-53343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow Commit 44e9a3bb76e5 (\"ARM: 9430/1: entry: Do a dummy read from VMAP shadow\") added a dummy read from the KASAN VMAP stack shadow in __switch_to(). The read uses ldr, but the KASAN shadow address is byte-granular and is not guaranteed to be word aligned. ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to() with an alignment exception before reaching init. Use ldrb for the dummy shadow access. The code only needs to fault in the shadow mapping if the stack shadow is missing, so a byte load is sufficient and matches the granularity of KASAN shadow memory.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53184", "url": "https://ubuntu.com/security/CVE-2026-53184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: \tif (skb->dev) \t\tcaller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53185", "url": "https://ubuntu.com/security/CVE-2026-53185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d (\"zram: fix synchronous reads\") for the same reason; the write_partial counterpart was missed.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53190", "url": "https://ubuntu.com/security/CVE-2026-53190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53198", "url": "https://ubuntu.com/security/CVE-2026-53198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which \"goto out\"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53356", "url": "https://ubuntu.com/security/CVE-2026-53356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)", "cve_priority": "high", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53345", "url": "https://ubuntu.com/security/CVE-2026-53345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically \"misses\" a push to the dirty ring is irrelevant.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53209", "url": "https://ubuntu.com/security/CVE-2026-53209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53347", "url": "https://ubuntu.com/security/CVE-2026-53347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix driver removal with disabled KMS DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-43116", "url": "https://ubuntu.com/security/CVE-2026-43116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-53214", "url": "https://ubuntu.com/security/CVE-2026-53214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF | RTF_PREFIX_RT' flags which are not set on fib6_null_entry. 2. modify_prefix_route(): Fixed by commit a747e02430df (\"ipv6: avoid possible NULL deref in modify_prefix_route()\"). 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for fib6_null_entry and returns an error. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [...] Call Trace: __kasan_check_byte (mm/kasan/common.c:573) lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1)) _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1)) cleanup_prefix_route (net/ipv6/addrconf.c:1280) ipv6_del_addr (net/ipv6/addrconf.c:1342) inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119) inet6_rtm_deladdr (net/ipv6/addrconf.c:4812) rtnetlink_rcv_msg (net/core/rtnetlink.c:6997) netlink_rcv_skb (net/netlink/af_netlink.c:2555) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1899) __sock_sendmsg (net/socket.c:802 (discriminator 4)) ____sys_sendmsg (net/socket.c:2698) ___sys_sendmsg (net/socket.c:2752) __sys_sendmsg (net/socket.c:2784) 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:121)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53349", "url": "https://ubuntu.com/security/CVE-2026-53349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.", "cve_priority": "low", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53230", "url": "https://ubuntu.com/security/CVE-2026-53230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53232", "url": "https://ubuntu.com/security/CVE-2026-53232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53236", "url": "https://ubuntu.com/security/CVE-2026-53236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53350", "url": "https://ubuntu.com/security/CVE-2026-53350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53237", "url": "https://ubuntu.com/security/CVE-2026-53237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [] lr : [] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-53242", "url": "https://ubuntu.com/security/CVE-2026-53242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53352", "url": "https://ubuntu.com/security/CVE-2026-53352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63870", "url": "https://ubuntu.com/security/CVE-2026-63870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit() The aoe driver (or similar) generates a non-IPv6 packet (e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit() on a 6LoWPAN interface (configured by the user or test case). Since the packet is not IPv6, the 6LoWPAN header_ops->create function (lowpan_header_create or header_create) returns early without initializing the lowpan_addr_info structure in the skb headroom. In the transmit function (lowpan_xmit), the driver calls lowpan_header (or setup_header) which unconditionally copies and uses the lowpan_addr_info from the headroom, which contains uninitialized data. Fix this by dropping non IPv6 packets. A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63868", "url": "https://ubuntu.com/security/CVE-2026-63868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: garp: fix unsigned integer underflow in garp_pdu_parse_attr The receive-side GARP attribute parser computes dlen with reversed operands: dlen = sizeof(*ga) - ga->len; ga->len is the on-wire attribute length and includes the GARP attribute header. For normal attributes with data, ga->len is larger than sizeof(*ga), so the subtraction underflows in unsigned arithmetic. The resulting value is later passed to garp_attr_lookup(), whose length argument is u8. After truncation, the parsed data length usually no longer matches the length stored for locally registered attributes, so received Join/Leave events are ignored. This breaks the GARP receive path for common attributes, such as GVRP VLAN registration attributes. Compute the data length as the attribute length minus the header length.", "cve_priority": "medium", "cve_public_date": "2026-07-19 15:16:00 UTC" }, { "cve": "CVE-2026-53353", "url": "https://ubuntu.com/security/CVE-2026-53353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 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:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 ", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53267", "url": "https://ubuntu.com/security/CVE-2026-53267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53274", "url": "https://ubuntu.com/security/CVE-2026-53274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent the issue.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-63898", "url": "https://ubuntu.com/security/CVE-2026-63898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+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 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-43311", "url": "https://ubuntu.com/security/CVE-2026-43311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: soc/tegra: pmc: Fix unsafe generic_handle_irq() call Currently, when resuming from system suspend on Tegra platforms, the following warning is observed: WARNING: CPU: 0 PID: 14459 at kernel/irq/irqdesc.c:666 Call trace: handle_irq_desc+0x20/0x58 (P) tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 The warning occurs because generic_handle_irq() is being called from a non-interrupt context which is considered as unsafe. Fix this warning by deferring generic_handle_irq() call to an IRQ work which gets executed in hard IRQ context where generic_handle_irq() can be called safely. When PREEMPT_RT kernels are used, regular IRQ work (initialized with init_irq_work) is deferred to run in per-CPU kthreads in preemptible context rather than hard IRQ context. Hence, use the IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT kernels, the IRQ work is processed in hardirq context instead of being deferred to a thread which is required for calling generic_handle_irq(). On non-PREEMPT_RT kernels, both init_irq_work() and IRQ_WORK_INIT_HARD() execute in IRQ context, so this change has no functional impact for standard kernel configurations. [treding@nvidia.com: miscellaneous cleanups]", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43240", "url": "https://ubuntu.com/security/CVE-2026-43240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: add a sanity check on previous kernel's ima kexec buffer When the second-stage kernel is booted via kexec with a limiting command line such as \"mem=\", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b (\"of: check previous kernel's ima-kexec-buffer against memory bounds\") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-23346", "url": "https://ubuntu.com/security/CVE-2026-23346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "low", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2026-52944", "url": "https://ubuntu.com/security/CVE-2026-52944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTL_SET_SPARSE FSCTL_SET_SPARSE in fsctl_set_sparse() modifies the file's sparse attribute and saves it through xattr without any permission checks. This exposes two issues: 1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check test_tree_conn_flag(work->tcon, KSMBD_TREE_CONN_FLAG_WRITABLE), but FSCTL_SET_SPARSE does not. 2) Even on writable shares, clients without FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here. Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-64006", "url": "https://ubuntu.com/security/CVE-2026-64006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ]", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-43331", "url": "https://ubuntu.com/security/CVE-2026-43331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ]", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-53358", "url": "https://ubuntu.com/security/CVE-2026-53358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.", "cve_priority": "medium", "cve_public_date": "2026-07-02 15:17:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-68768", "url": "https://ubuntu.com/security/CVE-2025-68768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:15:00 UTC" }, { "cve": "CVE-2026-43303", "url": "https://ubuntu.com/security/CVE-2026-43303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: clear page->private in free_pages_prepare() Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values. This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash: KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860 Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63886", "url": "https://ubuntu.com/security/CVE-2026-63886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the \"0b\" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64000", "url": "https://ubuntu.com/security/CVE-2026-64000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix potential OOB access in supervision frame handling Ensure the entire TLV header is linearized before access by adding sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this, a truncated frame could cause an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53131", "url": "https://ubuntu.com/security/CVE-2026-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-146.146 -proposed tracker (LP: #2166353)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", "", " * Bluetooth fails to initialize due to a kernel NULL pointer error", " (LP: #2165873)", " - Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c", "", " * Dell Precision fails to shutdown when HDMI display is connected (22.04", " HWE) (LP: #2164507)", " - drm/i915/vbt: Add fields dedicated_external and dyn_port_over_tc", " - drm/i915/display: Handle dedicated external ports in", " intel_encoder_is_tc()", "", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", "", " * [SRU] HPE: Fix for UBSAN array-index-out-of-bounds (LP: #2161004)", " - x86/platform/uv: Fix UBSAN array-index-out-of-bounds", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough", " (LP: #2089306)", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Reboot machine with ext4 configured to data=journal could dump spurious", " call trace (LP: #2164716)", " - ext4: clear stale xarray tags on folios skipped during writeback", "", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", "", " * [HP][ZBook Power 16 G11] Laptop freezed after upgrading the BIOS", " (LP: #2132119)", " - PCI/ASPM: Avoid L0s for Realtek RTS525A", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796)", " - netfilter: bitwise: rename some boolean operation functions", " - netfilter: bitwise: add support for doing AND, OR and XOR directly", " - drm/fbdev-helper: Set and clear VGA switcheroo client from fb_info", " - arm64: io: Rename ioremap_prot() to __ioremap_prot()", " - Disable -Wattribute-alias for clang-23 and newer", " - netfilter: xt_NFQUEUE: prefer raw_smp_processor_id", " - drm/imx: Fix three kernel-doc warnings in dcss-scaler.c", " - pcnet32: stop holding device spin lock during napi_complete_done", " - net: Annotate sk->sk_write_space() for UDP SOCKMAP.", " - net: lan743x: permit VLAN-tagged packets up to configured MTU", " - net: fec: fix pinctrl default state restore order on resume", " - Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame()", " extension handling", " - Bluetooth: MGMT: Fix backward compatibility with userspace", " - ptp: vclock: Switch from RCU to SRCU", " - octeontx2-af: npc: Fix CPT channel mask in npc_install_flow", " - vxlan: vnifilter: send notification on VNI add", " - vxlan: vnifilter: fix spurious notification on VNI update", " - ipmi: Fix rcu_read_unlock to srcu_read_unlock in handle_read_event_rsp", " - time: Fix off-by-one in settimeofday() usec validation", " - tools/rv: Fix cleanup after failed trace setup", " - arm64: tlb: Allow XZR argument to TLBI ops", " - iomap: don't revert iov_iter on partially completed buffered writes", " - net/mlx4: avoid GCC 10 __bad_copy_from() false positive", " - r8152: handle the return value of usb_reset_device()", " - rds: mark snapshot pages dirty in rds_info_getsockopt()", " - net: mvpp2: Add metadata support for xdp mode", " - net: mvpp2: build skb from XDP-adjusted data on XDP_PASS", " - clk: qcom: dispcc-sc8280xp: Don't park mdp_clk_src at registration time", " - tracing/probes: Point the error offset correctly for eprobe argument", " error", " - mmc: litex_mmc: Use DIV_ROUND_UP for more accurate clock calculation", " - USB: serial: option: add usb-id for Dell Wireless DW5826e-m", " - ALSA: timer: Fix UAF at snd_timer_user_params()", " - drm/amd/display: Reject gpio_bitshift >= 32 in", " bios_parser_get_gpio_pin_info()", " - mm/damon/ops-common: call folio_test_lru() after folio_get()", " - ARM: socfpga: Fix OF node refcount leak in SMP setup", " - ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O", " - mptcp: fix retransmission loop when csum is enabled", " - mptcp: sockopt: check timestamping ret value", " - selftests: mptcp: add test for extra_subflows underflow on userspace PM", " - ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write", " - inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush", " - pidfd: refuse access to tasks that have started exiting harder", " - i2c: stm32f7: fix timing computation ignoring i2c-analog-filter", " - i2c: tegra: Fix NOIRQ suspend/resume", " - Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)", " - Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard", " - net/mlx5: Reorder completion before putting command entry in", " cmd_work_handler", " - net: mv643xx: fix OF node refcount", " - octeontx2-af: fix memory leak in rvu_setup_hw_resources()", " - mmc: core: Fix host controller programming for fixed driver type", " - mmc: litex_mmc: Set mandatory idle clocks before CMD0", " - mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC", " - mmc: sdhci: add signal voltage switch in sdhci_resume_host", " - slimbus: qcom-ngd-ctrl: fix OF node refcount", " - drm/amdgpu: restart the CS if some parts of the VM are still invalidated", " - fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling", " - driver core: reject devices with unregistered buses", " - mm/hugetlb: avoid false positive lockdep assertion", " - soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get()", " - ipmi:ssif: Remove unnecessary indention", " - ipmi:ssif: NULL thread on error", " - selftests: mptcp: drop nanoseconds width specifier", " - tty: serial: samsung: use u32 for register interactions", " - RDMA/umem: fix kernel-doc warnings", " - RDMA: Move DMA block iterator logic into dedicated files", " - arm64: cputype: Add NVIDIA Olympus definitions", " - arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU", " - mptcp: add-addr: always drop other suboptions", " - mptcp: fix missing wakeups in edge scenarios", " - Revert \"selftest/ptp: update ptp selftest to exercise the gettimex", " options\"", " - ARM: fix hash_name() fault", " - wifi: remove zero-length arrays", " - soc: qcom: ice: Return -ENODEV if the ICE platform device is not found", " - Bluetooth: ISO: Fix not using bc_sid as advertisement SID", " - octeontx2-pf: Fix NDC sync operation errors", " - octeontx2-af: Fix initialization of mcam's entry2target_pffunc field", " - ima: kexec: skip IMA segment validation after kexec soft reboot", " - ima: kexec: move IMA log copy from kexec load to execute", " - gpio: zynq: fix runtime PM leak on remove", " - writeback: Avoid contention on wb->list_lock when switching inodes", " - writeback: Fix use after free in inode_switch_wbs_work_fn()", " - xfrm: hold device only for the asynchronous decryption", " - KVM: VMX: Update SVI during runtime APICv activation", " - drm/xe: fix refcount leak in xe_range_fence_insert()", " - slimbus: qcom-ngd-ctrl: Fix up platform_driver registration", " - slimbus: qcom-ngd-ctrl: Fix probe error path ordering", " - slimbus: qcom-ngd-ctrl: Initialize controller resources in controller", " - slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership", " - slimbus: qcom-ngd-ctrl: Balance pm_runtime enablement for NGD", " - drm/amd/pm: fix smu13 power limit default/cap calculation", " - drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in", " set_soft_freq_limited_range", " - drm/amd/display: add missing CSC entries for BT.2020 for DCE IPs", " - mailbox: Fix NULL message support in mbox_send_message()", " - vsock/virtio: fix skb overhead accounting to preserve full buf_alloc", " - net: introduce EXPORT_IPV6_MOD() and EXPORT_IPV6_MOD_GPL()", " - mptcp: pm: fix extra_subflows underflow on userspace PM subflow creation", " - vsock/virtio: fix skb overhead overflow on 32-bit builds", " - Upstream stable to v6.6.143, v6.12.94", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53132", " - vsock/virtio: fix potential unbounded skb queue", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53138", " - drm/amd/display: Bound VBIOS record-chain walk loops", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53140", " - drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53332", " - slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53156", " - nvmem: core: fix use-after-free bugs in error paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53202", " - accel/ivpu: Fix signed integer truncation in IPC receive", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53205", " - accel/ivpu: Add bounds checks for firmware log indices", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53210", " - tee: shm: fix shm leak in register_shm_helper()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-31663", " - xfrm: hold dev ref until after transport_finish NF_HOOK", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53220", " - netfilter: revalidate bridge ports", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53229", " - net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46203", " - spi: cadence-quadspi: fix unclocked access on unbind", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63871", " - Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53251", " - Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63869", " - wifi: mac80211: limit injected antenna index in", " ieee80211_parse_tx_radiotap", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53261", " - devlink: Release nested relation on devlink free", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53262", " - l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses", " - arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-45850", " - ipvs: skip ipv6 extension headers for csum checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53133", " - RDMA/umem: Fix truncation for block sizes >= 4G", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52908", " - RDMA: During rereg_mr ensure that REREG_ACCESS is compatible", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53199", " - hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53134", " - netfilter: nft_fib: fix stale stack leak via the OIFNAME register", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63883", " - serial: qcom_geni: fix kfifo underflow when flush precedes DMA", " completion IRQ", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64528", " - tty: serial: samsung: Remove redundant port lock acquisition in rx", " helpers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53329", " - drm/amd/display: Use krealloc_array() in dal_vector_reserve()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53135", " - drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53136", " - drm/amd/display: Clamp VBIOS HDMI retimer register count to array size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53137", " - drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53143", " - drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on", " GFX11", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53144", " - drm/amdkfd: fix NULL dereference in get_queue_ids()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53331", " - slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53146", " - thunderbolt: Limit XDomain response copy to actual frame size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53147", " - thunderbolt: Validate XDomain request packet size before type cast", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53148", " - thunderbolt: Clamp XDomain response data copy to allocation size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53149", " - thunderbolt: Bound root directory content to block size", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53150", " - thunderbolt: Reject zero-length property entries in validator", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52929", " - sctp: stream: fully roll back denied add-stream state", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52917", " - sctp: diag: reject stale associations in dump_one path", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53154", " - mm/hugetlb: restore reservation on error in hugetlb folio copy paths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53336", " - nvmem: layouts: onie-tlv: fix hang on unknown types", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53337", " - net: bonding: fix NULL pointer dereference in bond_do_ioctl()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53158", " - misc: fastrpc: Fix NULL pointer dereference in rpmsg callback", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53159", " - misc: fastrpc: fix DMA address corruption due to find_vma misuse", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53160", " - misc: fastrpc: fix use-after-free race in fastrpc_map_create", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53161", " - misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52930", " - ipc/shm: serialize orphan cleanup with shm_nattch updates", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53339", " - i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53168", " - fuse: reject fuse_notify() pagecache ops on directories", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53177", " - bnxt_en: Fix NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53181", " - vsock/vmci: fix sk_ack_backlog leak on failed handshake", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53182", " - wifi: nl80211: reject oversized EMA RNR lists", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53183", " - mptcp: allow subflow rcv wnd to shrink", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63867", " - mptcp: close TOCTOU race while computing rcv_wnd", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53343", " - ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53184", " - udp: clear skb->dev before running a sockmap verdict", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53185", " - zram: fix use-after-free in zram_bvec_write_partial()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53190", " - drm/virtio: fix dma_fence refcount leak on error in", " virtio_gpu_dma_fence_wait()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53194", " - USB: serial: kl5kusb105: fix bulk-out buffer overflow", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53195", " - USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53196", " - USB: serial: io_ti: fix heap overflow in get_manuf_info()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52935", " - xfrm: espintcp: do not reuse an in-progress partial send", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53198", " - ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53356", " - drm/i915/gem: Fix phys BO pread/pwrite with offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53345", " - KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53208", " - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53209", " - Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53213", " - drm/vc4: fix krealloc() memory leak", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53347", " - drm/virtio: Fix driver removal with disabled KMS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43116", " - netfilter: ctnetlink: ensure safe access to master conntrack", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53214", " - ipv6: Fix a potential NPD in cleanup_prefix_route()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53217", " - net: mvpp2: sync RX data at the hardware packet offset", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53218", " - netfilter: nft_exthdr: fix register tracking for F_PRESENT flag", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52942", " - netfilter: nf_log: validate MAC header was set before dumping it", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53219", " - netfilter: x_tables: avoid leaking percpu counter pointers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53349", " - netfilter: nf_conntrack: destroy stale expectfn expectations on", " unregister", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52939", " - net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic", " completion", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53223", " - net: guard timestamp cmsgs to real error queue skbs", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53227", " - net: openvswitch: fix possible kfree_skb of ERR_PTR", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53230", " - net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52947", " - net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53232", " - net: phy: clean the sfp upstream if phy probing fails", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53236", " - tcp: restrict SO_ATTACH_FILTER to priv users", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53350", " - ASoC: wm_adsp: Fix NULL dereference when removing firmware controls", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53237", " - gpio: mvebu: fix NULL pointer dereference in suspend/resume", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53238", " - netlabel: validate unlabeled address and mask attribute lengths", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53239", " - xfrm: policy: fix use-after-free on inexact bin in", " xfrm_policy_bysel_ctx()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-46320", " - tap: free page on error paths in tap_get_user_xdp()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53242", " - ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked", " streams", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53352", " - signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53245", " - net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63870", " - ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53249", " - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53252", " - Bluetooth: fix memory leak in error path of hci_alloc_dev()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53253", " - Bluetooth: bnep: reject short frames before parsing", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53254", " - Bluetooth: RFCOMM: validate skb length in MCC handlers", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53255", " - Bluetooth: MGMT: validate advertising TLV before type checks", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53256", " - Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63868", " - net: garp: fix unsigned integer underflow in garp_pdu_parse_attr", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53353", " - hsr: Remove WARN_ONCE() in hsr_addr_is_self().", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53263", " - 6lowpan: fix off-by-one in multicast context address compression", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53264", " - net/sched: act_api: use RCU with deferred freeing for action lifecycle", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53265", " - dm cache policy smq: check allocation under invalidate lock", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53266", " - netfilter: bridge: make ebt_snat ARP rewrite writable", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53267", " - netfilter: nft_ct: bail out on template ct in get eval", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53268", " - netfilter: conntrack_irc: fix possible out-of-bounds read", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53269", " - netfilter: synproxy: add mutex to guard hook reference counting", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53270", " - ipvs: clear the svc scheduler ptr early on edit", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53273", " - tee: optee: prevent use-after-free when the client exits before the", " supplicant", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53274", " - net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-53275", " - ipv6: mcast: Fix use-after-free when processing MLD queries", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52948", " - i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-63898", " - USB: serial: mct_u232: fix memory corruption with small endpoint", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52910", " - bpf: Free reuseport cBPF prog after RCU grace period.", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43311", " - soc/tegra: pmc: Fix unsafe generic_handle_irq() call", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-43240", " - x86/kexec: add a sanity check on previous kernel's ima kexec buffer", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-23346", " - arm64: io: Extract user memory type in ioremap_prot()", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-52944", " - ksmbd: fix FSCTL permission bypass by adding a permission check for", " FSCTL_SET_SPARSE", "", " * Noble update: upstream stable patchset 2026-08-21 (LP: #2164796) //", " CVE-2026-64006", " - netfilter: nf_tables: fix dst corruption in same register operation", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547)", " - Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size", " - drm/v3d: Fix use-after-free of CPU job query arrays on error path", " - drm/v3d: Release indirect CSD GEM reference on CPU job free", " - xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit", " - net/sched: sch_sfb: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - bcache: fix uninitialized closure object", " - nfc: llcp: Fix use-after-free in llcp_sock_release()", " - nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()", " - xfrm: Check for underflow in xfrm_state_mtu", " - nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems", " - kunit: fix use-after-free in debugfs when using kunit.filter", " - netfilter: xt_cpu: prefer raw_smp_processor_id", " - vsock: keep poll shutdown state consistent", " - net: netlink: fix sending unassigned nsid after assigned one", " - net: netlink: don't set nsid on local notifications", " - net/smc: Do not re-initialize smc hashtables", " - net/iucv: fix locking in .getsockopt", " - scsi: core: Run queues for all non-SDEV_DEL devices from", " scsi_run_host_queues", " - ipv4: free net->ipv4.sysctl_local_reserved_ports after", " unregister_net_sysctl_table()", " - ALSA: pcm: oss: Fix setup list UAF on proc write error", " - ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors", " - gpio: mxc: fix irq_high handling", " - ethtool: rss: fix hkey leak when indir_size is 0", " - ASoC: codecs: simple-mux: Fix enum control bounds check", " - Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()", " - bonding: refuse to enslave CAN devices", " - ethtool: eeprom: add missing ethnl_ops_begin() / _complete() during", " fallback", " - ethtool: eeprom: add more safeties to EEPROM Netlink fallback", " - net/sched: Revert \"net/sched: Restrict conditions for adding duplicating", " netems to qdisc tree\"", " - net/handshake: Use spin_lock_bh for hn_lock", " - nvme-tcp: store negative errno in queue->tls_err", " - net/handshake: Pass negative errno through handshake_complete()", " - Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success", " - Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp", " - Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close", " - gpio: rockchip: convert bank->clk to devm_clk_get_enabled()", " - net: mana: Add NULL guards in teardown path to prevent panic on attach", " failure", " - sctp: fix race between sctp_wait_for_connect and peeloff", " - ipv6: fix possible infinite loop in rt6_fill_node()", " - ipv6: fix possible infinite loop in fib6_select_path()", " - net: skbuff: fix pskb_carve leaking zcopy pages", " - perf: Fix dangling cgroup pointer in cpuctx", " - batman-adv: tvlv: abort OGM send on tvlv append failure", " - batman-adv: tt: reject oversized local TVLV buffers", " - batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface", " - batman-adv: iv: recover OGM scheduling after forward packet error", " - batman-adv: tp_meter: avoid role confusion in tp_list", " - batman-adv: tp_meter: directly shut down timer on cleanup", " - batman-adv: tt: avoid empty VLAN responses", " - batman-adv: bla: avoid double decrement of bla.num_requests", " - media: rc: fix race between unregister and urb/irq callbacks", " - media: rc: ttusbir: fix inverted error logic", " - inet: frags: add inet_frag_queue_flush()", " - HID: core: Add printk_ratelimited variants to hid_warn() etc", " - drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register", " - drm/i915/psr: Read Intel DPCD workaround register", " - drm/dp: Add eDP 1.5 bit definition", " - drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used", " - phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X", " - batman-adv: tt: prevent TVLV entry number overflow", " - iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer", " - usb: typec: ucsi: ccg: reject firmware images without a ':' record", " header", " - usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload", " VDO", " - usb: typec: altmodes/displayport: validate count before reading Status", " Update VDO", " - usb: typec: wcove: don't write past struct pd_message in", " wcove_read_rx_buffer()", " - usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT", " - usb: typec: ucsi: validate connector number in ucsi_connector_change()", " - USB: serial: safe_serial: fix memory corruption with small endpoint", " - media: rc: igorplugusb: fix control request setup packet", " - Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free()", " - HID: quirks: Add ALWAYS_POLL quirk for SIGMACHIP USB mouse", " - Bluetooth: btusb: Allow firmware re-download when version matches", " - hpfs: fix a crash if hpfs_map_dnode_bitmap fails", " - auxdisplay: line-display: fix OOB read on zero-length message_store()", " - Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn", " - Bluetooth: HIDP: fix missing length checks in hidp_input_report()", " - Bluetooth: ISO: fix UAF in iso_recv_frame", " - Bluetooth: ISO: serialize iso_sock_clear_timer with socket lock", " - Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync", " - Input: xpad - fix out-of-bounds access for Share button", " - parport: Fix race between port and client registration", " - USB: cdc-acm: Fix bit overlap and move quirk definitions to header", " - KVM: arm64: PMU: Preserve AArch32 counter low bits", " - KVM: SVM: Flush the current TLB when transitioning from xAVIC => x2AVIC", " - iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux", " - iio: adc: npcm: fix unbalanced clk_disable_unprepare()", " - iio: dac: max5821: fix return value check in powerdown sync", " - iio: dac: ad5686: fix input raw value check", " - iio: dac: ad5686: acquire lock when doing powerdown control", " - iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw", " - iio: gyro: itg3200: fix i2c read into the wrong stack location", " - iio: gyro: adis16260: fix division by zero in write_raw", " - iio: ssp_sensors: cancel delayed work_refresh on remove", " - iio: temperature: tsys01: fix broken PROM checksum validation", " - iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL", " - iio: light: cm3323: fix reg_conf not being initialized correctly", " - iio: buffer: hw-consumer: fix use-after-free in error path", " - USB: serial: omninet: fix memory corruption with small endpoint", " - usb: cdns3: gadget: fix request skipping after clearing halt", " - usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy", " acquisition failure", " - usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently", " leaks the runtime PM usage counter across bind/unbind cycles", " - usb: dwc2: Fix use after free in debug code", " - Input: elan_i2c - validate firmware size before use", " - wireguard: send: append trailer after expanding head", " - bpf: sockmap: fix tail fragment offset in bpf_msg_push_data", " - macsec: fix replay protection at XPN lower-PN wrap", " - ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params", " - ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().", " - ipv6: validate extension header length before copying to cmsg", " - xfrm: input: hold netns during deferred transport reinjection", " - ip6: vti: Use ip6_tnl.net in vti6_changelink().", " - HID: wacom: Fix OOB write in wacom_hid_set_device_mode()", " - iommu, debugobjects: avoid gcc-16.1 section mismatch warnings", " - nfc: hci: fix out-of-bounds read in HCP header parsing", " - xfrm: route MIGRATE notifications to caller's netns", " - xfrm: ah: use skb_to_full_sk in async output callbacks", " - ALSA: scarlett2: Fix 2i2 Gen 4 direct monitor gain on firmware 2417", " - netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without", " direction check", " - ASoC: qcom: q6asm-dai: close stream only when running", " - ASoC: qcom: q6asm-dai: do not set stream state in event and trigger", " callbacks", " - Input: xpad - add \"Nova 2 Lite\" from GameSir", " - Input: xpad - add support for ASUS ROG RAIKIRI II", " - ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops", " - Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem", " - Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490", " - comedi: comedi_test: fix check for valid scan_begin_src in", " waveform_ai_cmdtest()", " - comedi: comedi_test: Fix limiting of convert_arg in", " waveform_ai_cmdtest()", " - counter: Fix refcount leak in counter_alloc() error path", " - tty: serial: pch_uart: add check for dma_alloc_coherent()", " - usb: chipidea: core: convert ci_role_switch to local variable", " - usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval", " - USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub", " controllers", " - usb: storage: Add quirks for PNY Elite Portable SSD", " - usbip: vudc: Fix use after free bug in vudc_remove due to race condition", " - usb: usbtmc: check URB actual_length for interrupt-IN notifications", " - usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize", " - USB: serial: option: add MeiG SRM813Q", " - USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL", " - USB: serial: belkin_sa: validate interrupt status length", " - USB: serial: cypress_m8: validate interrupt packet headers", " - USB: serial: keyspan: fix missing indat transfer sanity check", " - USB: serial: mxuport: fix memory corruption with small endpoint", " - USB: serial: mct_u232: fix missing interrupt-in transfer sanity check", " - usb: gadget: uvc: hold opts->lock across XU walks in uvc_function_bind", " - usb: gadget: net2280: Fix double free in probe error path", " - usb: gadget: f_hid: fix device reference leak in hidg_alloc()", " - usb: gadget: composite: fix integer underflow in WebUSB GET_URL handling", " - usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports", " - usb: gadget: f_fs: copy only received bytes on short ep0 read", " - thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()", " - thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow", " - scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker", " - scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32", " - drm/hyperv: validate resolution_count and fix WIN8 fallback", " - drm/hyperv: validate VMBus packet size in receive callback", " - drm/i915: Fix potential UAF in TTM object purge", " - drm/amd/pm/si: Disregard vblank time when no displays are connected", " - serial: altera_jtaguart: handle uart_add_one_port() failures", " - serial: qcom-geni: fix UART_RX_PAR_EN bit position", " - serial: sh-sci: fix memory region release in error path", " - serial: zs: Fix swapped RI/DSR modem line transition counting", " - serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma", " - drm/amdkfd: fix NULL pointer bug in svm_range_set_attr", " - drm/amdkfd: fix a vulnerability of integer overflow in kfd debugger", " - drm/amdkfd: Check for pdd drm file first in CRIU restore path", " - serial: dz: Fix bootconsole message clobbering at chip reset", " - serial: dz: Fix bootconsole handover lockup", " - serial: dz: Convert to use a platform device", " - serial: zs: Fix bootconsole handover lockup", " - serial: zs: Switch to using channel reset", " - serial: zs: Convert to use a platform device", " - USB: serial: cypress_m8: fix memory corruption with small endpoint", " - USB: serial: digi_acceleport: fix memory corruption with small endpoints", " - xhci: tegra: Fix ghost USB device on dual-role port unplug", " - iommu: Skip PASID validation for devices without PASID capability", " - x86/boot: Disable stack protector for early boot code", " - rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg", " - rxrpc: Fix RESPONSE packet verification to extract skb to a linear", " buffer", " - serdev: Provide a bustype shutdown function", " - Bluetooth: hci_qca: Migrate to serdev specific shutdown function", " - Bluetooth: hci_qca: Convert timeout from jiffies to ms", " - ALSA: scarlett2: Return ENOSPC for out-of-bounds flash writes", " - ALSA: scarlett2: Allow flash writes ending at segment boundary", " - mm/memory: fix spurious warning when unmapping device-private/exclusive", " pages", " - platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery", " - net: hsr: defer node table free until after RCU readers", " - mptcp: pm: fix ADD_ADDR timer infinite retry on option space", " insufficient", " - ice: fix VF queue configuration with low MTU values", " - mptcp: cleanup fallback dummy mapping generation", " - mptcp: reset rcv wnd on disconnect", " - arm64: tlb: Flush walk cache when unsharing PMD tables", " - octeontx2-pf: avoid double free of pool->stack on AQ init failure", " - mptcp: introduce the mptcp_init_skb helper", " - mptcp: handle first subflow closing consistently", " - mptcp: do not drop partial packets", " - mm/damon/sysfs-schemes: delete tried region in regions_rmdirs()", " - iio: chemical: scd30: Use guard(mutex) to allow early returns", " - iio: chemical: scd30: fix division by zero in write_raw", " - iio: dac: ad5686: fix ref bit initialization for single-channel parts", " - ALSA: firewire-motu: Protect register DSP event queue positions", " - usb: dwc3: xilinx: fix error handling in zynqmp init error paths", " - usb: musb: omap2430: Fix use-after-free in omap2430_probe()", " - usb: typec: ucsi: Check if power role change actually happened before", " handling", " - thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()", " - usb: typec: ucsi: Don't update power_supply on power role change if not", " connected", " - hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with", " pmbus_lock", " - hwmon: (pmbus/adm1266) serialize NVMEM blackbox read with pmbus_lock", " - hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock", " - mm: perform all memfd seal checks in a single place", " - mm/memfd: fix spelling and grammatical issues", " - memfd: deny writeable mappings when implying SEAL_WRITE", " - usb: core: Fix SuperSpeed root hub wMaxPacketSize", " - Upstream stable to v6.12.93", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43331", " - x86/kexec: Disable KCOV instrumentation after load_segments()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52943", " - net: skbuff: fix missing zerocopy reference in pskb_carve helpers", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53358", " - Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52923", " - ipc: limit next_id allocation to the valid ID range", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2025-68768", " - inet: frags: flush pending skbs in fqdir_pre_exit()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43303", " - mm/page_alloc: clear page->private in free_pages_prepare()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52934", " - batman-adv: tvlv: reject oversized TVLV packets", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52913", " - batman-adv: v: stop OGMv2 on disabled interface", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46322", " - tun: free page on build_skb failure in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-46321", " - tun: free page on short-frame rejection in tun_xdp_one()", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-52927", " - netfilter: ebtables: fix OOB read in compat_mtw_from_user", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-43219", " - net: cpsw_new: Fix potential unregister of netdev that has not been", " registered yet", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-45930", " - net: mctp: ensure our nlmsg responses are initialised", "", " * Noble update: upstream stable patchset 2026-07-22 (LP: #2161547) //", " CVE-2026-53080", " - net/sched: cls_fw: fix NULL dereference of \"old\" filters before change()", "", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Enable CONFIG_ARM64_ERRATUM_4118414", "", " * CVE-2025-10263", " - arm64: cputype: Add C1-Ultra definitions", " - arm64: cputype: Add C1-Premium definitions", "", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", "", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", "", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", "", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", "", " * CVE-2026-63886", " - scsi: target: iscsi: Validate CHAP_R length before base64 decode", "", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", "", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", "", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", "", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", "", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", "", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", "", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", "", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", "", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", "", " * CVE-2026-64000", " - net: hsr: fix potential OOB access in supervision frame handling", "", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", "", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", "", " * CVE-2026-53131", " - netfilter: require Ethernet MAC header before using eth_hdr()", "" ], "package": "linux", "version": "6.8.0-146.146", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2166353, 1786013, 2165873, 2164507, 2163508, 2161004, 2089306, 2164716, 2164516, 2132119, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2164796, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547, 2161547 ], "author": "Edoardo Canepa ", "date": "Thu, 03 Sep 2026 17:47:58 +0300" } ], "notes": "linux-tools-6.8.0-147-generic version '6.8.0-147.147' (source package linux version '6.8.0-147.147') was added. linux-tools-6.8.0-147-generic version '6.8.0-147.147' has the same source package name, linux, as removed package linux-headers-6.8.0-142. As such we can use the source package version of the removed package, '6.8.0-142.142', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-6.8.0-142", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "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-headers-6.8.0-142-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-6.8.0-142-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "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-142-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-tools-6.8.0-142", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-tools-6.8.0-142-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-142.142", "version": "6.8.0-142.142" }, "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 20260926 to 20261017", "from_series": "noble", "to_series": "noble", "from_serial": "20260926", "to_serial": "20261017", "from_manifest_filename": "daily_manifest.previous", "to_manifest_filename": "manifest.current" }